[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
[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
[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
[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
[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