Virtual Hosts Configuration

[danielagatt]

Why am I getting the following error when I try to configure a nw virtual host?

It seems that I have the classpath set incorrectly...no? I have listed the error that I'm getting as well as the contents of the jboss-service.xml file.

15:14:23,171 INFO [SARDeployer] looking for nested deployments in : file:/home/apps/jboss-3.2.0_tomcat-4.1.24/server/to
mcat/conf/jboss-service.xml
15:14:24,440 WARN [ServiceConfigurator] Failed to complete install
java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.web.catalina.EmbeddedCatalinaServiceSX
at org.jboss.mx.loading.LoadMgr.beginLoadTask(LoadMgr.java:161)
at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:175)
at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:822)
at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:294)
at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:321)
at org.jboss.system.ServiceCreator.install(ServiceCreator.java:85)
at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:155)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:118)
at org.jboss.system.ServiceController.install(ServiceController.java:225)
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:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
at $Proxy5.install(Unknown Source)
at org.jboss.deployment.SARDeployer.create(SARDeployer.java:199)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:784)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:639)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:597)
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:324)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
at $Proxy6.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:361)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:268)
at org.jboss.Main.boot(Main.java:156)
at org.jboss.Main$1.run(Main.java:394)
at java.lang.Thread.run(Thread.java:536)
15:14:24,457 INFO [Log4jService] Creating

--------------------------------

The following are the contents of my jboss-service.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server>
<!-- $Id: jboss-minimal.xml,v 1.4.2.2 2003/02/24 08:02:30 ejort Exp $ -->

<!-- ===================================================================== -->
<!-- -->
<!-- A minimal JBoss Server Configuration -->
<!-- -->
<!-- ===================================================================== -->



<!-- Load all jars from the JBOSS_DIST/server//lib directory. This
can be restricted to specific jars by specifying them in the archives
attribute.
-->


<!-- ==================================================================== -->
<!-- Log4j Initialization -->
<!-- ==================================================================== -->

resource:log4j.xml


<!-- ==================================================================== -->
<!-- JNDI -->
<!-- ==================================================================== -->


<!-- The listening port for the bootstrap JNP service. Set this to -1
to run the NamingService without the JNP invoker listening port.
-->
1099



<!-- ==================================================================== -->
<!-- Deployment Scanning -->
<!-- ==================================================================== -->

<!-- An mbean for hot deployment/undeployment of archives.
-->


<depends optional-attribute-name="Deployer">jboss.system:service=MainDeployer

<!-- The URLComparator can be used to specify a deployment ordering
for deployments found in a scanned directory. The class specified
must be an implementation of java.util.Comparator, it must be able
to compare two URL objects, and it must have a no-arg constructor.
Two deployment comparators are shipped with JBoss:
- org.jboss.deployment.DeploymentSorter
Sorts by file extension, as follows:
"sar", "service.xml", "rar", "jar", "war", "wsr", "ear", "zip",
"*"
- org.jboss.deployment.scanner.PrefixDeploymentSorter
If the name portion of the url begins with 1 or more digits, those
digits are converted to an int (ignoring leading zeroes), and
files are deployed in that order. Files that do not start with
any digits will be deployed last, and they will be sorted by
extension as above with DeploymentSorter.
-->
org.jboss.deployment.DeploymentSorter
<!-- The Filter specifies a java.io.FileFilter for scanned
directories. Any file not accepted by this filter will not be
deployed. The org.jboss.deployment.scanner.DeploymentFilter
rejects the following patterns:
"#*", "%*", ",*", ".*", "_$*", "*#", "*$", "*%", "*.BAK",
"*.old", "*.orig", "*.rej", "*.bak", "*,v", "*~", ".make.state",
".nse_depinfo", "CVS", "CVS.admin", "RCS", "RCSLOG", "SCCS",
"TAGS", "core", "tags"
-->
org.jboss.deployment.scanner.DeploymentFilter

5000

<!-- URLs are comma seperated and unprefixed arguments are considered
file URLs and resolve relative to server home(JBOSS_DIST/server/default)
unless the given path is absolute. Any referenced directories cannot
be unpackaged archives, use the parent directory of the unpacked
archive.
-->

deploy/



<!-- The embedded Tomcat-4.x(Catalina) service configuration -->





















cct






<!-- A HTTP Connector on port 8080 -->

[jonlee]

This doesn't look right to me. The server/tomcat/conf/jboss-service.xml file can probably be left as is - unless you have some specific JBoss-related services to configure. Your embedded Tomcat is located in server/tomcat/deploy/jbossweb-tomcat.sar. What you want to control is the "embedded Tomcat configuration" located at server/tomcat/deploy/jbossweb-tomcat.sar/META-INF/jboss-service.xml.

It should look something like this:
<?xml version="1.0" encoding="UTF-8"?>

<!-- The service configuration for the embedded Tomcat4.1.x web container
-->




true

<!--
*******************************************************
****************** CLUSTERING *************************
*******************************************************
In order to activate HTTP Session clustering for Tomcat
make sure you run JBoss's "all" configuration i.e.
"run -c all"
(the default configuration doesn't contain clustering)

Furthermore, you may change SnapshotMode and
SnapshotInterval attributes below to indicate when to
synchronize changes with the other node(s).

If you use Apache+mod_jk(2) you will most probably use
the AJP1.3 connector below. Thus, if you so wish,
you may comment (i.e. deactivate) the HTTP connector
as it won't be used anymore.

*******************************************************
*******************************************************
*******************************************************
-->

<!--
If you are using clustering, the following two attributes
define when the sessions are replicated to the other nodes.
The default value, "instant", synchronously replicates changes
to the other nodes. In this case, the "SnapshotInterval" attribute
is not used.
The "interval" mode, in association with the "SnapshotInterval"
attribute, indicates that Tomcat will only replicates modified
sessions every "SnapshotInterval" miliseconds at most.
-->
instant <!-- you may switch to "interval" -->
2000








<!-- Access logger -->


<!-- Default context parameters -->





<!-- A HTTP/1.1 Connector on port 8080 -->


<!-- A AJP 1.3 Connector on port 8009 -->









If you are familiar with Tomcat, you'll see this is pretty much the Tomcat configuration. It doesn't handle contexts, root contexts and virtual hosts that well. But you can set up most of the other things as you would for Tomcat, particularly your listeners.

If you want contexts and virtual hosts, you can apply them by putting the definitions in a jboss-web.xml file located in the WEB-INF directory for your WAR (packed or unpacked).

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
<context-root>/</context-root>
<virtual-host>www.abc.com</virtual-host>
</jboss-web>

Unless you really want to run a bare-bones JBoss-Tomcat instance, you are probably best running the default instance - which means you need to make the edits to server/default/deploy/jbossweb-tomcat.sar/META-INF/jboss-service.xml and so forth. The default has the standard JBoss services enabled so is a better starting point.

Read the FAQs regarding embedded Jetty and Changes to 3.2.0 for some of the basics as well for a quick start.

[danielagatt]

ok thanks, i think I will be avoiding virtual hosts for now.

Now I've tried deploying a war file to ../server/tomcat/deploy and I'm getting the following error....

2003-05-08 16:32:48,259 ERROR [STDERR] java.io.IOException: Couldn't get lock for /home/apps/jboss-3.2.0_tomcat-4.1.24/s
erver/tomcat/tmp/deploy/server/tomcat/deploy/work/MainEngine/localhost/ota_terminal_customisation-2.0/WEB-INF/logs/ota_t
erminal_customisation-cct.log
2003-05-08 16:32:48,261 ERROR [STDERR] at java.util.logging.FileHandler.openFiles(FileHandler.java:361)
2003-05-08 16:32:48,261 ERROR [STDERR] at java.util.logging.FileHandler.(FileHandler.java:261)
2003-05-08 16:32:48,262 ERROR [STDERR] at vml.common.log.EventLog.initialise(EventLog.java:52)
2003-05-08 16:32:48,262 ERROR [STDERR] at vml.common.log.EventLog.logError(EventLog.java:68)
2003-05-08 16:32:48,262 ERROR [STDERR] at vml.common.db.DBConnectionPool.initialise(DBConnectionPool.java:64)
2003-05-08 16:32:48,262 ERROR [STDERR] at vml.common.db.DBConnectionPool.getConnection(DBConnectionPool.java:156)
2003-05-08 16:32:48,266 ERROR [STDERR] at vml.ota_terminal_customisation.DownloadSettingsBean.loadPhoneBrands(DownloadS
ettingsBean.java:62)

--------

Seems to me like this is because the war file is not being unpacked so the WEB-INF directory does not exist and the jvm cannot write to the file. This app works perfectly on my standalone Tomcat installation.

Is there anyway of getting round this?!

I also have classes in WEB-INF I hope that jboss will locate them...

Pls help I'm getting desparate!!!! I thought this would be chicken feed!!

[jonlee]

It is pretty straight-forward. The virtual hosts stuff is easy. Understanding what is going on so if things break you can fix them is the hard bit. ;) It looks like you are trying to get files that don't physically exist on your storage device.

One trap for the uninitiated - JBoss does not unpack the WAR file. So unlike a stand-alone Tomcat configuration, you don't ever have any separate and physical directories/files deployed. This is within the spec for app servers - app servers like SilverStream keep their deployments in a database so nothing ever physically exists. In this case (when a WAR is not unpacked), getting ServletContext.getRealPath() returns you null.

What you can do is manually unpack your WAR file into the deploy directory. Your topmost web application directory (in the deploy directory) must be called MyContext.war and the context will be deployed as MyContext. All your web application content unpacks into this directory. That most likely will fix your problem. As an example, look at jmx-console.war in your deploy directory. You get to that locally by http://localhost:8080/jmx-console.

Just remember, not all servlet containers necessarily unpack a WAR or EAR. Hope that helps.

[danielagatt]

Hi,

Thanks for your prompt feedback...very helpful!

I've managed to deploy most of my tomcat apps to the default jboss directory with the method you suggested.

Now I have just one prob...one of the applications seems to have deployed but I keep getting the no context error when I access the page. the log file lists the following error...

2003-05-09 11:00:43,518 INFO [org.jboss.web.localhost.Engine] StandardHost[localhost]: MAPPING configuration error for
request URI /4me

[danielagatt]

Problem solved. The problem seems to be related to the fact that the war file started with a digit.

Am I right? I now renamed the directory and it is working perfectly.

[jonlee]

Yes. The deployment doesn't take kindly to the context starting with a number. If you look carefully at the logs, you will probably see that the context is changed. For example, look at the effect of the rename of jmx-console.war to 4jmx-console.war and the reported mapping in the server.log file.

2003-05-09 19:47:35,417 INFO [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/Java/JBoss-3.2.0/server/default/deploy/4jmx-console.war/
2003-05-09 19:47:35,537 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] deploy, ctxPath=/jmx-console, warUrl=file:/C:/Java/JBoss-3.2.0/server/default/deploy/4jmx-console.war/

See the context path, ctxPath drops the digit.

;)

[danielagatt]

Thks.

I'm going to dare make my last question...sorry but I'm really new to JBoss and I'd like to discover its full potential!

How can I stop and start my services e.g. the v4me service in a similar way that is done in Tomcat Manager?

The problem is that on redeployment of a current app apparently db connections are not closed gracefully by JBoss like they are with Tomcat manager.

Thks in advance for your help!

[jonlee]

You can try using the jmx-console to destroy the web application before redeploying. I haven't tried this to kill an application gracefully. The interface is a bit clunky at this stage - hopefully we'll get to the sophistication of the WebSphere management console at some stage.

Medium term, you would use the JBoss managed connection pools so it won't have as much impact. You access this as you would any Java DataSource.

In the long-term, you would write EJBs to process and manage data. Your web application becomes the presentation layer and does little data management and processing - mainly manipulating the data given to it by the EJBs. At this stage, your web app is pretty much isolated from the actual data source.

Hope this helps.