Running multiple instances of JBOSS on single machine

There is a file called

${JBOSS_HOME}/docs/examples/binding-manager/sample-bindings.xml.

This file specifies a number of jboss port configurations such as ports-default, ports-01, and ports-02. Please note, however, that the number of port configurations is less than the number of groups in the class using the installed version of jboss. Therefore, create your own configuration, following the conventions (increment the second digit of each port number in the configuration, i.e., ports-default specifies port 8080 for the web server, ports-01 specifies 8180, and ports-02 specifies 8280). Update the value of each of the ports in the configuration, not just port 8080. To use a port configuration from sample-bindings.xml, make a few modifications to the file ${JBOSS_HOME}/server/conf/jboss-service.xml. Find the section of the file that looks like the XML code below. Note that is the close comment character. Therefore, notice that this section is currently entirely commented out. Instead, you want only the textual description to be commented out and uncomment the remaining part. Once the XML code is uncommented, you should specify the port configuration that you want to use. By default, once this code is uncommented, the system will use the ports-01 configuration. Instead, choose the port configuration that you want from your modified sample-bindings.xml file. <!-- Binding service manager for port/host mapping. This is a sample config that demonstrates a JBoss instances with a server name 'jboss1' loading its bindings from an XML file using the ServicesStoreFactory implementation returned by the XMLServicesStoreFactory. ServerName: The unique name assigned to a JBoss server instance for lookup purposes. This allows a single ServicesStore to handle mulitiple JBoss servers. StoreURL: The URL string passed to org.jboss.services.binding.ServicesStore during initialization that specifies how to connect to the bindings store.

StoreFactory: The org.jboss.services.binding.ServicesStoreFactory interface implementation to create to obtain the ServicesStore instance.

<mbean code="org.jboss.services.binding.ServiceBindingManager" name="jboss.system:service=ServiceBindingManager"> <attribute name="ServerName">ports-01</attribute> <attribute name="StoreURL">../docs/examples/binding-manager/sample-bindings.xml</attribute> <attribute name="StoreFactoryClassName"> org.jboss.services.binding.XMLServicesStoreFactory </attribute> </mbean> --> Thats all!!... Now run your server :)

---

In case if the server throws the following exception during startup org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.services.binding.ServiceBindingManager; - nested throwable: (java.lang. ClassNotFoundException: No ClassLoaders found for: org.jboss.services.binding.ServiceBindingManager) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:139)

In order to resolve the problem copy the file bindingservice-plugin.jar from the directory JBOSS_HOME/server/standard/lib to the directory JBOSS_HOME/server/lib or JBOSS_HOME//lib.

Detecting Disconnected Network Cable through Java Sockets

It would be my guess that there seems to be a misunderstanding of what sockets do and what the phyiscal layer (the cable) has to do with it. First a socket is a virtual connection. The cable has nothing to do with it. There is no way that a socket knows that a cable has been pulled. If you need that information then you are going to have to use something besides a socket. A socket however can tell you if a communication has failed. But that only happens when you send something. Reading something will not do it. You might expect to receive something on a socket in a given time period and thus a read "fails." But that has nothing to do with the socket itself. You have to write code to do that yourself (and that is a limitation of the socket not java.) When a socket sends something it uses UDP or TCP (at least in java.) With UDP it just goes. There is never a failure even if it doesn't go anywhere. With TCP the TCP protocol (software, nothing to do with hardware like cables) waits for a receipt response for a fixed length of time. If it doesn't receive the receipt it sends the message again. It keeps doing this several times until it finally gives up. The only change you can make to this is how many times it tries and how long it waits. This is often a operating system wide change. So if you reduce it you better make real sure that you don't expect traffic with another device. Especially a internet device. Reference : http://forum.java.sun.com/thread.jspa?threadID=316842&messageID=1604338