Port differentiation for war deployments?

[gretel]

I'm on JBoss 3.2.3 with Tomcat. Is there any way I can configure my server to run different web applications (i.e., war deployments) on different ports? Example config files would be greatly appreciated!

thanks,

gretel

[gretel]

OK. solved it well enough to meet my needs, but not as far as I'd like.

This solution allows me to deploy ear files to the normal deploy directory and serve the contained war files up on port 18080. A special set of private web applications are served up on port 58080. The downside is that I couldn't find a way to deploy ear files on the private port. I had to extract the contained war files to directories to do so, which had implications for classloading and class sharing that I wasn't happy about.

Here's what I did:

Created separate directories under <jboss.home> to contain web application content. Each of these content directories contains jsps, other resources and the WEB-INF directory with web.xml, etc.

Modified /deploy/jbossweb-tomcat41.sar/META-INF/jboss-service.xml to add another Service element. This server has a Connector which listens on a new port. In addition to the DefaultContext, for this new Service, added several new Context elements which defined the docBase="${jboss.server.home.dir}/private/" (absolute path to the directories mentioned above) and defined the path attribute path="/myApp" as the root identifier of the web app. I'd like to post the jboss-service.xml here, but I haven't had much luck with posting XML to these forums (can anyone suggest how to post XML without losing tags?). If someone can suggest how to do that I'll post the xml file.

There were classloader issues which I wasn't able to resolve as cleanly as I'd like: These new web apps didn't have access to classes loaded by jboss or other web apps, they seems isolated. So I created lib directories under each WEB-INF and dropped copies of all necessary jars in and things work.

gretel

[gretel]

p.s.,

the Context docBase attributes are of the form docBase="${jboss.server.home.dir}/private/", not terminating in private as I had earlier written

I believe the reason I'm having classloader issues is that the private webapps use their own independent WAR classloaders, which have no EJB classloader parent which have loaded all the core jboss libraries. I suspect the reason for this is that the web content is not packaged in an ear file, so they don't get an EJB classloader which might have a more complete vision of JBoss's classes. Any insight into this would be appreciated.

gretel

[gretel]

p.s.s,

I see that this nasy posting software is preventing me from posting accurately. I'll try again:

the docBase attribute mentioned above ends in the name of the directory which contains the web app, eg. docBase="${jboss.server.home.dir}/private/theWebAppDirectory.

gretel

[darranl]

this nasy posting software

Is developed here.

[gretel]

Ah, its the

Code

tag...

<?xml version="1.0" encoding="UTF-8"?>

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

 <mbean code="org.jboss.web.tomcat.tc4.EmbeddedTomcatService"
 name="jboss.web:service=WebServer">

 <!-- Get the flag indicating if the normal Java2 parent first class
 loading model should be used over the servlet 2.3 web container first
 model.
 -->
 <attribute name="Java2ClassLoadingCompliance">true</attribute>

 <attribute name="LenientEjbLink">true</attribute>

 <!-- A flag indicating if the JBoss Loader should be used. This loader
 uses a unified class loader as the class loader rather than the tomcat
 specific class loader.
 -->
 <attribute name="UseJBossWebLoader">true</attribute>

 <!-- The name of the request attribute under with the authenticated JAAS
 Subject is stored on successful authentication. If null or empty then
 the Subject will not be stored.
 -->
 <attribute name="SubjectAttributeName">j_subject</attribute>

 <!--
 *******************************************************
 ****************** 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.
 -->
 <attribute name="SnapshotMode">instant</attribute> <!-- you may switch to "interval" -->
 <attribute name="SnapshotInterval">2000</attribute>

 <attribute name="Config">
 <Server>
 <Service name="JBoss-Tomcat-Public">
 <Engine name="MainEngine" defaultHost="localhost">
 <Logger className="org.jboss.web.tomcat.Log4jLogger"
 verbosityLevel="debug" category="org.jboss.web.localhost.Engine"/>
 <Host name="localhost">

 <!-- Access logger -->
 <Valve className="org.apache.catalina.valves.AccessLogValve"
 prefix="localhost_access" suffix=".log"
 pattern="common" directory="${jboss.server.home.dir}/log"/>

 <!-- This valve clears any caller identity set by the realm
 and provides access to the realm about the existence of an
 authenticated caller to allow a web app to run with a realm
 that support unauthenticated identities. It also establishes
 any run-as principal for the servlet being accessed.
 -->
 <Valve className="org.jboss.web.tomcat.security.SecurityAssociationValve"/>
 <!-- Default context parameters -->
 <DefaultContext cookies="true" crossContext="true" override="true"/>

 </Host>
 </Engine>

 <!-- A HTTP/1.1 Connector on port 18080 -->
 <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
 address="${jboss.bind.address}" port="18080" minProcessors="5" maxProcessors="100"
 enableLookups="true" acceptCount="10" debug="0"
 connectionTimeout="20000" useURIValidationHack="false"/>

 </Service>

 <Service name="JBoss-Tomcat-Private">
 <Engine name="MainEngine" defaultHost="localhost">
 <Logger className="org.jboss.web.tomcat.Log4jLogger"
 verbosityLevel="debug" category="org.jboss.web.localhost.Engine"/>
 <Host name="localhost" appBase="${jboss.server.home.dir}/private">

 <!-- Access logger -->
 <Valve className="org.apache.catalina.valves.AccessLogValve"
 prefix="localhost_access" suffix=".log"
 pattern="common" directory="${jboss.server.home.dir}/log"/>

 <!-- This valve clears any caller identity set by the realm
 and provides access to the realm about the existence of an
 authenticated caller to allow a web app to run with a realm
 that support unauthenticated identities. It also establishes
 any run-as principal for the servlet being accessed.
 -->
 <Valve className="org.jboss.web.tomcat.security.SecurityAssociationValve"/>

 <!-- Default context parameters -->
 <DefaultContext cookies="true" crossContext="true" override="true"/>

 <Context cookies="true" crossContext="true" override="true"
 docBase="${jboss.server.home.dir}/private/MyApp1"
 path="/app1">
 </Context>

 <Context cookies="true" crossContext="true" override="true"
 docBase="${jboss.server.home.dir}/private/MyApp2"
 path="/app2">
 </Context>

 </Host>

 </Engine>

 <!-- A HTTP/1.1 Connector on port 18081 -->
 <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
 address="${jboss.bind.address}" port="18081" minProcessors="5" maxProcessors="100"
 enableLookups="true" acceptCount="10" debug="0"
 connectionTimeout="20000" useURIValidationHack="false"/>

 </Service>
 </Server>
 </attribute>
 <depends>jboss:service=TransactionManager</depends>
 </mbean>

</server>