January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1437) Unresolvable host name aborts server startup

by Nicklas Karlsson (JIRA)

Unresolvable host name aborts server startup -------------------------------------------- Key: AS7-1437 URL: https://issues.jboss.org/browse/AS7-1437 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.0.0.Final Reporter: Nicklas Karlsson Assignee: Jason Greene Starting AS7 on a host with a non-resolvable hostname fails with 13:48:46,158 ERROR [stderr] Exception in thread "Controller Boot Thread" java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration 13:48:46,159 ERROR [stderr] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:89) 13:48:46,159 ERROR [stderr] at java.lang.Thread.run(Thread.java:722) 13:48:46,159 ERROR [stderr] Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: Failed to parse configuration 13:48:46,160 ERROR [stderr] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:115) 13:48:46,160 ERROR [stderr] at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:104) 13:48:46,160 ERROR [stderr] at org.jboss.as.server.ServerService.boot(ServerService.java:193) 13:48:46,160 ERROR [stderr] at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:83) 13:48:46,164 ERROR [stderr] ... 1 more 13:48:46,164 ERROR [stderr] Caused by: java.lang.RuntimeException: Unable to determine a default name based on the local host name 13:48:46,165 ERROR [stderr] at org.jboss.as.controller.parsing.CommonXml.getDefaultName(CommonXml.java:184) 13:48:46,165 ERROR [stderr] at org.jboss.as.controller.parsing.StandaloneXml.readServerElement(StandaloneXml.java:137) 13:48:46,165 ERROR [stderr] at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:91) 13:48:46,165 ERROR [stderr] at org.jboss.as.controller.parsing.StandaloneXml.readElement(StandaloneXml.java:79) 13:48:46,165 ERROR [stderr] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:100) 13:48:46,174 ERROR [stderr] at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:59) 13:48:46,174 ERROR [stderr] at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:107) 13:48:46,175 ERROR [stderr] ... 4 more 13:48:46,175 ERROR [stderr] Caused by: java.net.UnknownHostException: nikbox.fi.dom: nikbox.fi.dom 13:48:46,175 ERROR [stderr] at java.net.InetAddress.getLocalHost(InetAddress.java:1438) 13:48:46,175 ERROR [stderr] at org.jboss.as.controller.parsing.CommonXml.getDefaultName(CommonXml.java:182) 13:48:46,175 ERROR [stderr] ... 10 more 13:48:46,176 ERROR [stderr] Caused by: java.net.UnknownHostException: nikbox.fi.dom 13:48:46,176 ERROR [stderr] at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method) 13:48:46,177 ERROR [stderr] at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:866) 13:48:46,177 ERROR [stderr] at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1258) 13:48:46,177 ERROR [stderr] at java.net.InetAddress.getLocalHost(InetAddress.java:1434) 13:48:46,177 ERROR [stderr] ... 11 more One option would be to default to something if the operation fails so this wouldn't prevent server startup -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

6
9
0 / 0

[JBoss JIRA] (AS7-3512) logmodule on command line causes error in tools

by Max Rydahl Andersen (JIRA)

Max Rydahl Andersen created AS7-3512: ---------------------------------------- Summary: logmodule on command line causes error in tools Key: AS7-3512 URL: https://issues.jboss.org/browse/AS7-3512 Project: Application Server 7 Issue Type: Bug Components: Server Affects Versions: 7.1.0.Final Reporter: Max Rydahl Andersen Assignee: Jason Greene Priority: Critical jboss modules fails to start if you pass the previously required -logmodule option. Invalid option '-logmodule' this will break any tools that works with AS7.0-7.1CR1 by launching via jboss modules instead of the startup script. Please consider ignoring this option (possibly print out a warning) instead of failing hard. -- 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

14 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-2717) Reinstate @Ignored tests in RemotingSubsystemTestCase

by Kabir Khan (Created) (JIRA)

Reinstate @Ignored tests in RemotingSubsystemTestCase ----------------------------------------------------- Key: AS7-2717 URL: https://issues.jboss.org/browse/AS7-2717 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.0.Beta1 Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 7.1.0.CR1 These tests fail intermittently in some environments {code} ***org.jboss.as.remoting.RemotingSubsystemTestCase.testSubsystemWithThreadAttributeChange junit.framework.AssertionFailedError: expected not same at junit.framework.Assert.fail(Assert.java:50) at junit.framework.Assert.failSame(Assert.java:276) at junit.framework.Assert.assertNotSame(Assert.java:262) at junit.framework.Assert.assertNotSame(Assert.java:269) at org.jboss.as.remoting.RemotingSubsystemTestCase$CurrentConnectorAndController.checkStatus(RemotingSubsystemTestCase.java:273) at org.jboss.as.remoting.RemotingSubsystemTestCase$CurrentConnectorAndController.updateCurrentEndpoint(RemotingSubsystemTestCase.java:263) at org.jboss.as.remoting.RemotingSubsystemTestCase.updateAndCheckThreadAttribute(RemotingSubsystemTestCase.java:135) at org.jboss.as.remoting.RemotingSubsystemTestCase.testSubsystemWithThreadAttributeChange(RemotingSubsystemTestCase.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) ***org.jboss.as.remoting.RemotingSubsystemTestCase.testSubsystemWithConnectorPropertyChange junit.framework.AssertionFailedError: expected not same at junit.framework.Assert.fail(Assert.java:50) at junit.framework.Assert.failSame(Assert.java:276) at junit.framework.Assert.assertNotSame(Assert.java:262) at junit.framework.Assert.assertNotSame(Assert.java:269) at org.jboss.as.remoting.RemotingSubsystemTestCase$CurrentConnectorAndController.checkStatus(RemotingSubsystemTestCase.java:273) at org.jboss.as.remoting.RemotingSubsystemTestCase$CurrentConnectorAndController.updateCurrentConnector(RemotingSubsystemTestCase.java:267) at org.jboss.as.remoting.RemotingSubsystemTestCase.testSubsystemWithConnectorPropertyChange(RemotingSubsystemTestCase.java:164) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ***org.jboss.as.remoting.RemotingSubsystemTestCase.testSubsystemWithBadConnectorProperty junit.framework.AssertionFailedError: Expected no service jboss.remoting.endpoint.subsystem at junit.framework.Assert.fail(Assert.java:50) at org.jboss.as.remoting.RemotingSubsystemTestCase.testSubsystemWithBadConnectorProperty(RemotingSubsystemTestCase.java:201) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) {code} -- 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

14 years, 2 months

3
2
0 / 0

[JBoss JIRA] (JBRULES-3304) WorkItem unmarshalling does not use rulebase classloader

by Marco Rietveld (Created) (JIRA)

WorkItem unmarshalling does not use rulebase classloader -------------------------------------------------------- Key: JBRULES-3304 URL: https://issues.jboss.org/browse/JBRULES-3304 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.3.0.Final Reporter: Marco Rietveld Assignee: Marco Rietveld Priority: Minor Fix For: 5.3.1.Final Because the rulebase does not get inserted into the (marshaller) context that's used for unmarshalling a WorkItem(Info), when {{MarshallerReaderContext.resolveClass(ObjectStreamClass)}} get's called, it can not use the ruleBase's root class loader. If necessary, I can supply a test case for this to show where it goes wrong -- at the moment it disappeared with a stash I dropped so that I'll have to recreate it. -- 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

14 years, 3 months

3
2
0 / 0

[JBoss JIRA] (JBRULES-3321) isA operator does not work as expected with POJO facts

by Mike Melton (Created) (JIRA)

isA operator does not work as expected with POJO facts ------------------------------------------------------ Key: JBRULES-3321 URL: https://issues.jboss.org/browse/JBRULES-3321 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.3.0.Final Reporter: Mike Melton Assignee: Mark Proctor Priority: Minor Pasted from the rules-users list: I am having trouble getting the isA operator to work with POJO facts. The problem manifests in the IsAEvaluator.evaluate(...) method, line 163 (5.3.0.Final). This line checks whether the objectValue class is annotated with @Traitable. For a @Traitable fact fully declared in DRL, this line correctly evaluates to true. For a POJO fact which is declared @Traitable in DRL, this line evaluates to false. (I tried adding @Traitable to the POJO fact itself, which results in the line evaluating true, but the next line which casts to a TraitableBean fails.) I have attached a test demonstrating the problem. There are two DRL files, one which declares a fact entirely, and another which adds @Traitable to a POJO fact. The declared fact and the POJO fact have identical structure, and the rules are also otherwise identical. However, the declared test passes, while the POJO test fails. -- 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

14 years, 3 months

3
3
0 / 0

[JBoss JIRA] (JBRULES-3345) Allow traits to be declared explicitly

by Davide Sottara (JIRA)

Davide Sottara created JBRULES-3345: --------------------------------------- Summary: Allow traits to be declared explicitly Key: JBRULES-3345 URL: https://issues.jboss.org/browse/JBRULES-3345 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Components: drools-compiler (expert), drools-core Reporter: Davide Sottara Assignee: Davide Sottara Priority: Minor Fix For: 5.4.0.Beta2 Support "declare trait X ... end" in place of "declare X @format(trait) ... end", which breaks the intended semantics of @format. As alternatives, both "declare trait X ... end" and "declare X @kind(trait) ... end" will be supported. -- 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

14 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-3009) Provide for declarative Java 1.5 enum definiton in DRL

by Michael Anstis (JIRA)

Provide for declarative Java 1.5 enum definiton in DRL ------------------------------------------------------ Key: JBRULES-3009 URL: https://issues.jboss.org/browse/JBRULES-3009 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler (expert), drools-core (expert) Affects Versions: 5.2.0.M2 Reporter: Michael Anstis Assignee: Mark Proctor Java classes can be defined in DRL using the "declare" keyword. It would be good to be able to define Java 1.5 enums using "declare" too. We could then strip the proprietary "Guvnor style enums" from Guvnor and have the UI front DRL supported enums. Guvnor currently also supports related\dependent enums where the "list of values" for one enum is dependent upon the value from another enum: enum FUEL has values "Petrol" and "Diesel", enum FUEL_DERIVATIVE has values "Unleaded", "Super unleaded", "Bio-diesel" and "City disel". If FUEL.Petrol is selected then only FUEL_DERIVATIVE values of "Unleaded" and "Super unleaded" can be chosen. This functionality would still need to be provided by Guvnor as it is used as "author-time" restrictions not runtime. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-3153) ChangeSet loading will take 5 minutes without an internet conection

by Burkhard Vogel (JIRA)

ChangeSet loading will take 5 minutes without an internet conection ------------------------------------------------------------------- Key: JBRULES-3153 URL: https://issues.jboss.org/browse/JBRULES-3153 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.Final Reporter: Burkhard Vogel Assignee: Mark Proctor My knowledge agent takes about 5 min to read the changeset.xml, it happens an my servers that DON'T have internet access when reading (or better trying to read) http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-api/src/... - however its included in the knowledge-api jar. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
5
0 / 0

[JBoss JIRA] (AS7-3273) On managed domain server, add OperationEntry.Flag.PRIVATE to any subsystem operation that modifies the configuration

by Brian Stansberry (Created) (JIRA)

On managed domain server, add OperationEntry.Flag.PRIVATE to any subsystem operation that modifies the configuration -------------------------------------------------------------------------------------------------------------------- Key: AS7-3273 URL: https://issues.jboss.org/browse/AS7-3273 Project: Application Server 7 Issue Type: Sub-task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Blocker Fix For: 7.1.0.Final Same as AS7-3272, except for subsystems. This is a separate JIRA from AS7-3272 just as a means to divide the overall work into more manageable tasks. If someone takes on a piece of this task (i.e. a subsystem) please first record a comment in this JIRA stating you are doing so. This will prevent duplication of effort. -- 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

14 years, 3 months

2
1
0 / 0

[JBoss JIRA] (AS7-3272) On managed domain server, add OperationEntry.Flag.PRIVATE to any non-subsystem operation that modifies the configuration

by Brian Stansberry (Created) (JIRA)

On managed domain server, add OperationEntry.Flag.PRIVATE to any non-subsystem operation that modifies the configuration ------------------------------------------------------------------------------------------------------------------------ Key: AS7-3272 URL: https://issues.jboss.org/browse/AS7-3272 Project: Application Server 7 Issue Type: Sub-task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Blocker Fix For: 7.1.0.Final Go through ServerControllerModelUtil, find operations that are registered (including any registered by a ResourceDefinition.registerOperations() impl) and ensure that OperationEntry.Flag.PRIVATE is added to the operation's registration. This will remove the operation description from the end-user-visible management API. -- 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

14 years, 3 months

2
1
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 January 2012