October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should be skipped in case that patching module is not enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2421: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1020315|https://bugzilla.redhat.com/show_bug.cgi?id=1020315] from ASSIGNED to POST > PatchInfoUnitTestCase should be skipped in case that patching module is not enabled > ------------------------------------------------------------------------------------ > > Key: WFLY-2421 > URL: https://issues.jboss.org/browse/WFLY-2421 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Patching > Reporter: Jan Martiska > Assignee: Jan Martiska > Fix For: 8.0.0.CR1 > > > PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should be skipped in case that patching module is not enabled

by Jan Martiska (JIRA)

[ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.... ] Jan Martiska commented on WFLY-2421: ------------------------------------ https://github.com/wildfly/wildfly/pull/5386 > PatchInfoUnitTestCase should be skipped in case that patching module is not enabled > ------------------------------------------------------------------------------------ > > Key: WFLY-2421 > URL: https://issues.jboss.org/browse/WFLY-2421 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Patching > Reporter: Jan Martiska > Assignee: Jan Martiska > Fix For: 8.0.0.CR1 > > > PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should be skipped in case that patching module is not enabled

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2421?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-2421: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1020315 > PatchInfoUnitTestCase should be skipped in case that patching module is not enabled > ------------------------------------------------------------------------------------ > > Key: WFLY-2421 > URL: https://issues.jboss.org/browse/WFLY-2421 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Patching > Reporter: Jan Martiska > Assignee: Jan Martiska > Fix For: 8.0.0.CR1 > > > PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2421) PatchInfoUnitTestCase should be skipped in case that patching module is not enabled

by Jan Martiska (JIRA)

Jan Martiska created WFLY-2421: ---------------------------------- Summary: PatchInfoUnitTestCase should be skipped in case that patching module is not enabled Key: WFLY-2421 URL: https://issues.jboss.org/browse/WFLY-2421 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Patching Reporter: Jan Martiska Assignee: Jan Martiska Fix For: 8.0.0.CR1 PatchInfoUnitTestCase should be skipped (rather than report a fail) in case that patching module is not enabled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1725) JGroups testsuite output not processed correctly on Windows

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1725?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1725: --------------------------- Priority: Optional (was: Major) > JGroups testsuite output not processed correctly on Windows > ----------------------------------------------------------- > > Key: JGRP-1725 > URL: https://issues.jboss.org/browse/JGRP-1725 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.5 > Environment: Windows > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Priority: Optional > Fix For: 3.5 > > > When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1725) JGroups testsuite output not processed correctly on Windows

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1725?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1725: -------------------------------- So this issue is fixed then ? > JGroups testsuite output not processed correctly on Windows > ----------------------------------------------------------- > > Key: JGRP-1725 > URL: https://issues.jboss.org/browse/JGRP-1725 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.5 > Environment: Windows > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Priority: Optional > Fix For: 3.5 > > > When running the testsuite on Windows, testsuite output ends up on the console and not in the test case reports. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2352) Domain controller fails to restart due to an inconsistent rollback of a redeploy

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2352?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2352: ----------------------------------------------- Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1021763|https://bugzilla.redhat.com/show_bug.cgi?id=1021763] from NEW to POST > Domain controller fails to restart due to an inconsistent rollback of a redeploy > -------------------------------------------------------------------------------- > > Key: WFLY-2352 > URL: https://issues.jboss.org/browse/WFLY-2352 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Alpha4 > Reporter: Osamu Nagano > Assignee: Brian Stansberry > > When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down. > The domain controller fails to restart with the following log messages. > {code} > 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2420) Domain controller fails to restart due to an inconsistent rollback of a redeploy

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-2420?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-2420: ---------------------------------------- The issue here is during rollback the DeploymentFullReplace handler isn't checking whether the hash of the "replacement" deployment is the same as the hash of the "replaced" deployment before removing the content from the repo. This is true in standalone as well, although reproducing it would take more effort. These handlers (plural meaning the server and HC variants) can use a general cleanup too. They've gotten a bit convoluted. > Domain controller fails to restart due to an inconsistent rollback of a redeploy > -------------------------------------------------------------------------------- > > Key: WFLY-2420 > URL: https://issues.jboss.org/browse/WFLY-2420 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Beta1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 8.0.0.CR1 > > > Osamu Nagano reports: > When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down. > The domain controller fails to restart with the following log messages. > -- > 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." > 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. > -- > The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2420) Domain controller fails to restart due to an inconsistent rollback of a redeploy

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-2420: -------------------------------------- Summary: Domain controller fails to restart due to an inconsistent rollback of a redeploy Key: WFLY-2420 URL: https://issues.jboss.org/browse/WFLY-2420 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 8.0.0.Beta1 Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 8.0.0.CR1 Osamu Nagano reports: When you try to redeploy (or deploy with --force option) the same application which has the same contents hash, and a necessary dependency like a datasource beeing injected in the application is lost by some reason, the redeploy operation will delete the contents under $JBOSS_HOME/domain/data/content directory but won't delete entries in domain.xml. Then the domain controller fails to start up because no contents found in the directory. This likely happens when you frequently changes settings during other servers shutting down. The domain controller fails to restart with the following log messages. -- 12:04:10,623 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "exampleapp.war")]) - failure description: "JBAS010876: No deployment content with hash c1306bc4855f4ed9914c9616f2b999c5c62a79d3 is available in the deployment content repository for deployment 'exampleapp.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart." 12:04:10,628 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details. -- The domain controller should be independent from such a server specific issue and there should be a way to fix this via CLI or Console, not by a manual editing of domain.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2419) SFSBs should be distributable by default in HA profiles

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-2419: ---------------------------------- Summary: SFSBs should be distributable by default in HA profiles Key: WFLY-2419 URL: https://issues.jboss.org/browse/WFLY-2419 Project: WildFly Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 8.0.0.CR1 The @Clustered annotation currently has 2 orthogonal meanings: 1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem) 2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology. This is confusing. If I want to replicate the state of my SFSB, I have to annotate my bean with @Clustered. However, this annotation could be ignored if my server profile does not support it. So, effectively, my server profile ultimately dictates whether or not my SFSB's state gets replicated. If that's the case, why bother with requiring @Clustered at all? Additionally, EE7 adds spec support for specifying whether a given SFSB is passivation-capable. By default, the spec dictates that SFSBs are passivation capable. According to Section 4.6.5 of the EJB 3.2 specification (the section that describes passivationCapable): "Note: application server vendors may use passivation as a technique to provide high availability of stateful session beans by replicating their state from one JVM instance to another across which the container is distributed." Given this, it only seems natural that a server that provides high-availability to a SFSB that is passivation capable by default would have its state replicated by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2013