When starting up with a loopback address that is other than 127.0.0.1 (I'll get to that later), this exception happens: 14:31:16,275 ERROR [org.jboss.msc.service.fail] MSC00001: Failed to start service jboss.network.default: org.jboss.msc.service.StartException in service jboss.network.default: failed to resolve interface default at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:101) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1344) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_20] at java.lang.Thread.run(Thread.java:636) [:1.6.0_20] Now I have seen this msg not be displayed at all, so under some circumstances it is being lost. Now, for the loopback address issue. The libra (our cloud project) server instances generate unique loopback addresses, but do not want to create a unique loopback device or aliases on the loopback device for some reason. How do I specify that the default address should use a specific address, but still match the loopback interface? Looking at the interface-criteriaGroup schema, you cannot do something like? <interfaces> <interface name="default"> <inet-address value="127.0.250.5"/> <loopback /> </interface> _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I'm unclear about the exception message part: 1) Was the exception something you thought was incorrect behavior given your environment, or just what led you to investigate how to configure it correctly? 2) Darran Lofthouse was saying earlier today that he was seeing log messages getting swallowed somehow. Sounds like you are seeing something similiar. I've opened a JIRA. https://issues.jboss.org/browse/JBAS-9149

Scott, do you still have a complete log for the case where the exception does show up? I theorize that it happens very near to the time where we see: 15:42:46,306 INFO [org.jboss.as.logging] Removing bootstrap log handlers and sometimes happens just afterwards (but before the logging subsystem gets everything replaced). See JBAS-9149 for more details if you're interested in the theory. On 03/25/2011 02:43 PM, Scott Stark wrote: > It was 2, the exception was not showing up. Here is an example where > there is no exception, just an error about failed dependencies: > > [root@ip-10-78-94-50 bin]# ./standalone.sh > ========================================================================= > > JBoss Bootstrap Environment > > JBOSS_HOME: /var/lib/libra/sstark1/jboss-as7/test1/jboss-7.0.0 > > JAVA: /usr/lib/jvm/jre-1.6.0/bin/java > > JAVA_OPTS: -server -Xmx56m -XX:MaxPermSize=56m > -Dorg.jboss.resolver.warning=true > -Dsun.rmi.dgc.client.gcInterval=3600000 > -Dsun.rmi.dgc.server.gcInterval=3600000 > > ========================================================================= > > 15:42:44,964 INFO [org.jboss.modules] JBoss Modules version 1.0.0.Beta16 > 15:42:45,136 INFO [org.jboss.msc] JBoss MSC version 1.0.0.Beta7 > 15:42:45,179 INFO [org.jboss.as] JBoss AS 7.0.0.Beta2 "(TBD)" starting > 15:42:45,613 INFO [org.jboss.as.server] Activating core services > 15:42:45,718 INFO [org.jboss.as] creating native management service > using network interface (default) port (9999) > 15:42:45,725 INFO [org.jboss.as] creating http management service using > network interface (default) port (9990) > 15:42:45,740 INFO [org.jboss.as.arquillian] Activating Arquillian Subsystem > 15:42:45,747 INFO [org.jboss.as.ee] Activating EE subsystem > 15:42:45,779 INFO [org.jboss.as.naming] Activating Naming Subsystem > 15:42:45,919 INFO [org.jboss.as.connector.subsystems.datasources] > Deploying JDBC-compliant driver class org.h2.Driver (version 1.2) > 15:42:45,930 INFO [org.jboss.as.osgi] Activating OSGi Subsystem > 15:42:46,194 INFO [org.jboss.as.webservices] Activating WebServices > Extension > 15:42:46,301 INFO [org.jboss.as.naming] Starting Naming Service > 15:42:46,306 INFO [org.jboss.as.logging] Removing bootstrap log handlers > 15:42:46,371 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC > service thread 1-2) The Apache Tomcat Native library which allows > optimal performance in production environments was not found on the > java.library.path: > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib > 15:42:46,381 INFO [org.jboss.as.server.deployment] (MSC service thread > 1-3) Starting deployment of "ROOT.war" > 15:42:46,482 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss > Remoting version 3.1.0.Beta2 > 15:42:46,488 INFO [org.jboss.as.deployment] (MSC service thread 1-1) > Started FileSystemDeploymentService for directory > /var/lib/libra/sstark1/jboss-as7/test1/jboss-7.0.0/standalone/deployments > 15:42:46,491 WARN [org.jboss.vfs] (MSC service thread 1-3) VFS was > unable to set the URLStreamHandlerFactory. This will have unpredictable > results > 15:42:46,682 INFO [org.apache.catalina.core.StandardContext] (MSC > service thread 1-2) The listener > "com.sun.faces.config.ConfigureListener" is already configured for this > context. The duplicate definition has been ignored. > 15:42:46,797 INFO [org.jboss.web] (MSC service thread 1-2) registering > web context: > 15:42:46,798 INFO [org.jboss.as.server.deployment] (MSC service thread > 1-1) Deployment "ROOT.war" failed in 416 ms. Failed Dependencies: > [service > jboss.naming.context.java.comp.ROOT.ROOT.ROOT.TransactionSynchronizationRegistry, > service jboss.naming.context.java.comp.ROOT.ROOT.ROOT.UserTransaction] > 15:42:46,798 INFO [org.jboss.as] (MSC service thread 1-2) JBoss AS > 7.0.0.Beta2 "(TBD)" started in 2029ms - Started 90 of 133 services (26 > services are passive or on-demand) > 15:42:46,799 ERROR [org.jboss.as.server] (MSC service thread 1-1) Boot > update failed: "Deployment failed. Failed Dependencies: [service > jboss.naming.context.java.comp.ROOT.ROOT.ROOT.TransactionSynchronizationRegistry, > service jboss.naming.context.java.comp.ROOT.ROOT.ROOT.UserTransaction]" > > > > On 3/25/11 12:28 PM, Brian Stansberry wrote: >> I'm unclear about the exception message part: >> >> 1) Was the exception something you thought was incorrect behavior given >> your environment, or just what led you to investigate how to configure >> it correctly? >> >> 2) Darran Lofthouse was saying earlier today that he was seeing log >> messages getting swallowed somehow. Sounds like you are seeing something >> similiar. I've opened a JIRA. >> >> https://issues.jboss.org/browse/JBAS-9149 >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

My bad, I was reading the schema element incorrectly. That selection criteria is allowed and works.

So this is not working as I want, and cannot based on the current NetworkInterfaceService because it returns the address of the interface that matches as bind address. What I need is for the bind address to be taken from the criteria because the interface does not list all of the allowed bind addresses it supports. This is for a rhel instance where the loopback interface allows any 127.0.* address to be bound against it.