October 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5230) jboss-as maven plugin won't parse variables in filename configuration attribute

by Pete Muir (JIRA)

Pete Muir created AS7-5230: ------------------------------ Summary: jboss-as maven plugin won't parse variables in filename configuration attribute Key: AS7-5230 URL: https://issues.jboss.org/browse/AS7-5230 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.1.Final Reporter: Pete Muir Assignee: James Perkins If you try to use a variable here (e.g. ${project.artifactId}) then it doesn't get expanded. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] (JBASMP-30) jboss-as:run intermittently hangs with 100% CPU

by James Perkins (JIRA)

James Perkins created JBASMP-30: ----------------------------------- Summary: jboss-as:run intermittently hangs with 100% CPU Key: JBASMP-30 URL: https://issues.jboss.org/browse/JBASMP-30 Project: JBoss AS Maven Plugins Issue Type: Bug Affects Versions: 7.2.Final Reporter: James Perkins Assignee: James Perkins The run goal should return when the server has started but intermittently hangs with 100% CPU. I believe the cause to be flawed logic in the loop that checks for server startup. In Run.java:200 (7.2-FINAL), what is currently: {code} while (server.isRunning()) { } {code} i.e. if the server reaches a running state before this loop is reached then loop indefinitely It should instead be something like: {code} while (!server.isRunning()) { TimeUnit.MILLISECONDS.sleep(100L); } {code} For extra safety it should probably also respect the startup-timeout parameter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] (JBASMP-29) Commands executed out of order

by James Perkins (JIRA)

James Perkins created JBASMP-29: ----------------------------------- Summary: Commands executed out of order Key: JBASMP-29 URL: https://issues.jboss.org/browse/JBASMP-29 Project: JBoss AS Maven Plugins Issue Type: Bug Reporter: James Perkins Assignee: James Perkins In 7.2-Final, commands can be executed out of order but should instead respect the order in the POM. Commands.java currently declares commands as a Set, this should instead be a List. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
2
0 / 0

[JBoss JIRA] (AS7-5797) Save and Cancel at the top of the edit form make users jump around

by Catherine Robson (JIRA)

[ https://issues.jboss.org/browse/AS7-5797?page=com.atlassian.jira.plugin.s... ] Catherine Robson commented on AS7-5797: --------------------------------------- Can you have the edit button at the top, and then that goes away once you get into edit mode? Just the save and cancel move to the bottom. Like mentioned, you might want to keep an "easy cancel" towards the top if the user clicked edit by accident. > Save and Cancel at the top of the edit form make users jump around > ------------------------------------------------------------------ > > Key: AS7-5797 > URL: https://issues.jboss.org/browse/AS7-5797 > Project: Application Server 7 > Issue Type: Feature Request > Components: Console > Reporter: Heiko Braun > Assignee: Heiko Braun > Labels: uxp > Fix For: 7.2.0.CR1 > > > The typical form path is top to bottom. The save and cancel buttons should be placed at the bottom of the form to the left. If an “easy cancel” without scrolling to the bottom is needed, this should be handled separate- > ly from the main save and cancel action. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (AS7-5229) jboss-as maven plugin tries to deploy an artifact ending in .ejb for ejb packaging type

by Pete Muir (JIRA)

Pete Muir created AS7-5229: ------------------------------ Summary: jboss-as maven plugin tries to deploy an artifact ending in .ejb for ejb packaging type Key: AS7-5229 URL: https://issues.jboss.org/browse/AS7-5229 Project: Application Server 7 Issue Type: Feature Request Reporter: Pete Muir Assignee: James Perkins Fix For: 7.1.1.Final If you create an artifact with ejb type packaging, the produced artifact still has .jar as the filename extension of the resource to deploy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
3
0 / 0

[JBoss JIRA] (AS7-5800) Output the name and value of attributes that can't be replicated for easier tracking

by Chris Laprun (JIRA)

Chris Laprun created AS7-5800: --------------------------------- Summary: Output the name and value of attributes that can't be replicated for easier tracking Key: AS7-5800 URL: https://issues.jboss.org/browse/AS7-5800 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Affects Versions: 7.1.3.Final (EAP) Reporter: Chris Laprun Assignee: Paul Ferraro Priority: Minor Fix For: 7.1.4.Final (EAP) Currently, the only message when an attribute cannot be replicated is "Specified attribute cannot be replicated" which is not very helpful to track down and fix the problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
14
0 / 0

[JBoss JIRA] (AS7-5355) Grouping handler config of HornetQ not handled correctly

by Bryan Brouckaert (JIRA)

Bryan Brouckaert created AS7-5355: ------------------------------------- Summary: Grouping handler config of HornetQ not handled correctly Key: AS7-5355 URL: https://issues.jboss.org/browse/AS7-5355 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.3.0.Alpha1 Reporter: Bryan Brouckaert HornetQ Grouping Handler config does not work because it actually uses the Broadcast Group config. The bug is rather obivous if you look at the code change in the github pull request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
1
0 / 0

[JBoss JIRA] (AS7-5789) HttpService as optional capability

by Thomas Diesler (JIRA)

Thomas Diesler created AS7-5789: ----------------------------------- Summary: HttpService as optional capability Key: AS7-5789 URL: https://issues.jboss.org/browse/AS7-5789 Project: Application Server 7 Issue Type: Sub-task Components: OSGi, Web Reporter: Thomas Diesler Assignee: David Bosschaert Fix For: 7.2.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
4
0 / 0

[JBoss JIRA] (AS7-5801) Intermittent failures in PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix

by Brian Stansberry (JIRA)

Brian Stansberry created AS7-5801: ------------------------------------- Summary: Intermittent failures in PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix Key: AS7-5801 URL: https://issues.jboss.org/browse/AS7-5801 Project: Application Server 7 Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Fix For: 7.2.0.CR1 Reported on the TeamCity server Tomaz has set up: Build JBoss AS7 :: Windows testsuite - master-next #35 failed (Tests failed: 1 (1 new), passed: 3513, ignored: 88) Agent: build02 Changes included: 1 change. Change 48968c4f68c4ec3c6e3491fa1ab268fbb001cd0c by stuart.w.douglas(a)gmail.com (1 file): AS7-5786 Remote Naming 1.0.5.Final Failed tests summary: 1 (1 new) (new) org.jboss.as.controller.persistence.PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix details » Stacktraces: (new) org.jboss.as.controller.persistence.PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix java.lang.IllegalStateException: JBAS014647: Could not rename C:\BuildAgent\work\54c978af95cc0ab5\controller\target\persistence-test-configs\standard\standard_xml_history\current to C:\BuildAgent\work\54c978af95cc0ab5\controller\target\persistence-test-configs\standard\standard_xml_history\20121019-065647003 at org.jboss.as.controller.persistence.ConfigurationFile.createHistoryDirectory(ConfigurationFile.java:454) at org.jboss.as.controller.persistence.ConfigurationFile.successfulBoot(ConfigurationFile.java:303) at org.jboss.as.controller.persistence.PersistanceResourceTestCase.testNonPersistentConfigurationFileFromBackupUsingThePrefix(PersistanceResourceTestCase.java:463) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1514) RELAY2: store-and-forward inter-site messages to prevent message loss when site master crashes

by Bela Ban (JIRA)

Bela Ban created JGRP-1514: ------------------------------ Summary: RELAY2: store-and-forward inter-site messages to prevent message loss when site master crashes Key: JGRP-1514 URL: https://issues.jboss.org/browse/JGRP-1514 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.2 JGRP-1401 deals with crashes of the site master *within* the current site, and developed FORWARD_TO_COORD to deal with those temporary losses (a new coord will take over), to prevent message loss. *This* JIRA is about preventing message loss caused by the site master of a *remote site* crashing. The general idea is to store-and-forward a message for a certain time and/or a certain number of attempts to forward. The most frequent use case is probably that the site master of a remote site left (or crashed) and the new site master hasn't yet opened the bridge, so the message would be lost. Store-and-forward should help here. If we still cannot forward the message for a (configurable) time and/or number of tries, we'll send a SITE_UNREACHABLE message back to the original sender of the message, which will then have to deal with it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
6
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 2012