File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Servlets and the fly likes doubt in web app deployment Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "doubt in web app deployment" Watch "doubt in web app deployment" New topic

doubt in web app deployment

Sylven Yip
Ranch Hand

Joined: Aug 30, 2007
Posts: 42
can you tell me the detail about domain binding on the remote host?

if i develop an application named app1.war,should the client visit my web site by URL http://my domain/app1/ but that's no reasonable.

another question:
suppose i have a application named app1.war , this is the web site system.
now i want to add a bbs or blog module application to my web site.
shall i package the module application to a bbs.war and deploy on the remote host?and what about the domain binding?

Bear Bibeault
Author and ninkuma

Joined: Jan 10, 2002
Posts: 63858

Originally posted by Sylven Yip:
but that's no reasonable.
Why not? What would you consider reasonable? You didn't say.
[ October 10, 2007: Message edited by: Bear Bibeault ]

[Asking smart questions] [About Bear] [Books by Bear]
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17417

The host and domain names are defined for the machine as part of its network definition. You can only control them if you control the network. Additionally, the domain name has to be registered with one of the world's "telephone book" (DNS) if you want anyone anywhere on the Internet to be able to talk to that server by name.

The individual applications on a web application server are defined in terms of virtual hosts and contexts. Virtual hosts are simply alternate host names, so they also must be published in DNS. Some examples are "" and "", assuming that both the Javaranch website and the message board applications both reside on the same machine. There's also a reverse mechanism where multiple machines serve the same hostname, used when a cluster of servers is needed, but I'll leave that information for another day.

The actual webapp is published under a web application context URL. This is simply the part of the URL that is looked at to see where a given request will be routed. In this way, URLs going to can be routed to the accounting app and can be routed to the user registration app (I made these apps up - don't expect to actually click on the links and find anything).

The application context named "/" is the default context, if one has been defined. So "" might be routed to the default context (since it's not spelled right), where the default context app would look in its web.xml file (assuming a J2EE default app) and attempt to resolve a relative URL of '/acounting'. The web.xml pattern matchers don't include the host, domain or context URL parts of the incoming URL when they attempt to resolve what part of an app will handle a request.

When you publish a webapp, you bind it to the application context. By default, a lot of appservers will assign a context name that's the same as your WAR name if you don't specify an explicit context, but that's not true for all appservers.

An IDE is no substitute for an Intelligent Developer.
Sylven Yip
Ranch Hand

Joined: Aug 30, 2007
Posts: 42
thanks Tim.please bear in mind i have no experience about it.
but can the domain bind to a context (such as to ?
and the browser can visit to visit the app?

and if i deploy another web site named app2.i bind to

can this words?
Rahul Bhattacharjee
Ranch Hand

Joined: Nov 29, 2005
Posts: 2308
I am not sure that I have understood you question but here is what I have to say.

The HTTP request sends an additional HOST header with it so that various web domains can be configured in the same host.Virtual hosting.

Rahul Bhattacharjee
LinkedIn - Blog
Sylven Yip
Ranch Hand

Joined: Aug 30, 2007
Posts: 42
i understand now.
It is sorta covered in the JavaRanch Style Guide.
subject: doubt in web app deployment
It's not a secret anymore!