You may wish to run different web applications on different ports. For example, you might want an admin application on a different port than a production application.
This example also demonstrates how to start listening on the ports after the web applications are fully deployed and ready to be used.
Tomcat example
In non-geronimo tomcat, you can do this by including two or more server definitions in your server.xml file, and including the applications in the server elements. It's possible to set up essentially the same structure in geronimo.
Here's the sample app:
http://issues.apache.org/jira/secure/attachment/12334215/appPerPort.ear
If you unpack it you can deploy it inplace with something like
java -jar bin/deployer.jar deploy --inPlace appPerPort.ear
(Assuming you have logged in to the deployer previously)
Here's the plan, with some explanation. The first thing that happens is that the gbeans in the ear scope start; this starts 2 tomcat servers but no connectors for them.
Then the three web apps start in order. The first two are actual web apps with content. Note that each has a web-container gbean-link to the appropriate web container that just started.
The third web app has the connector gbeans for the web containers we started. Note that the web apps are modules as well as the ear itself, and that web modules start in the same order as they are listed in application.xml. Recall also that in order for a module to start, all its gbeans must start completely. Therefore we have first the tomcat containers starting, then the web apps deployed onto different tomcat containers, and finally once the web apps are completely started, the connectors that open listeners on the two different ports.
Putting the connector gbeans into an otherwise empty web app succeeds in delaying opening the ports until after the applications are ready, but is not exactly elegant. If you are willing to have more than one module, you can put the connector gbeans into a service plan and list the ear as a dependency to get the same effect.
Jetty
Jetty web apps have the same ability to specify which jetty container should be used, however I don't have a sample plan to demonstrate that it works.
There may be a simpler way to limit which ports an app in a jetty web container is available on, in which case for jetty one would not need 2 jetty containers. This requires further investigation.
1 Comment
Lasantha Ranaweera
The ear provided with this sample application is has a problem (it is not an EAR, that is why it give an error in deployment).
Also there is a problem in the geronimo-application.xml file too. From G 1.1 <conext-prority-classloader> tag has been removed from XML schemas. Users has to comment that tag too (I am not 100% sure the consiquences of removing this tag in a large application).
But it didn't affected this sample application. Application works fine after removing it too.![(smile)](/confluence/s/p9b4rx/8804/1naq7q0/_/images/icons/emoticons/smile.svg)
Herewith I have attached new version of this sample application which can be build using an Ant build script. Follow the given instructions to test this version of sample.
Building, Deploying and Testing
1. Download the Port file.
2. Decompressing Port.zip file will create Port folder.
3. Open a new command prompt and navigate in to the Port folder and give ant command. It will create appPerPort.ear under <app_home>/releases folder.
4. Deploy appPerPort.ear using Geronimo console.
5. Open 2 web browser consoles and point each of them in to
http://localhost:8081/war1/page1.jsp
http://localhost:8082/war2/page2.jsp