• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Using "E:\Prasanna's Collection\Projects\Apache Tomcat" instead of "webapps"

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Created a new folder ContextRoot inside D:\Program_Files\Apache_Tomcat
2. Created another folder META-INF inside Apache_Tomcat
3. Created context.xml file inside META-INF
Apache_Tomcat >ContextRoot > META-INF > context.xml
The content of context.xml is like this:


When I open localhost:8080, Apache Tomcat welcomes me, am I missing something?

 
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the JavaRanch, Prasanna!

Tomcat cannot run arbitrary collections of files. You must supply it either with a WAR file structured per the J2EE spec or the unzipped equivalent ("exploded" WAR).

You also have to tell Tomcat where to find the WAR. The popular way is to dump it under TOMCAT_HOME/webapps, which is the default location. WARs placed there will automatically be deployed (and by default, ".war" files will be exploded and Tomcat will then use the exploded version of the WAR). If the WAR contains a META-INF/context.xml file, then the information in that file will be used to configure the webapp.

Alternatively you can explicitly point to an alternate WAR location by creating an external context file and copying that file to TOMCAT_HOME/conf/Catalina/localhost. In that case, Tomcat will deploy the webapp, using the context file's docBase attribute as the filesystem location for the WAR file or WAR directory. The context path will be set to the name of the context file, minus its ".xml" extension, so for example, if your context file was named "javaranch.xml", then the webapp context base would be "http://hostname:8080/javaranch".

You are attempting to use the "path" attribute of your Context element as a filesystem path. That's not what it's for. The "path" attribute defines the context path for client URLs, not a filesystem path. It is also completely ignored in many cases, where the actual deployed context path is derived from the name of the context file or of the war file/directory.

Incidentally, filesystem pathnames with spaces and characters such as the apostrophe in "Prasanna's" can cause problems when various software services mis-understand what you mean. Keep your directory names simple and you'll have less trouble.
 
Prasanna Adh
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Tim for the reply, its difficult for me to grab the concept that you are trying to tell, but I figured out that I have to google WAR, and isn't it possible to place any file in localhot:8080 which creates a link to my own desired folder, so that I can place my projects there?
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can't "place a file" in "localhost:8080", because files and URLs are 2 different things. URLs look something like Unix filesystem pathnames, but they are actually just logical identifiers to the webapp server which then serves up the resource that corresponds to its URL (which, after all means Uniform Resource Locator). The confusion arises because in many webapp servers, the easy way for the web application to manage static resources with complex pathnames is to simply use a directory structure that mirrors the URL structure.

But aside from that, there's also the requirement that all J2EE-compliant webapps must be in the structure of a WAR - you cannot just throw files in anywhere and have the webapp server deal with them. A webapp server isn't a file server.

On the other hand, you can put WARs almost anywhere that Tomcat has read access for. I often put my production wars under /opt/com/mousetech/mywebappname/mywebappname.war, for example. I also do this with the WAR products that my application builds create, which saves me the extra step of copying the WAR to a special server location. By setting up a suitable Context file in TOMCAT_HOME/Catalina/localhost whose codeBase points to the output of my build (for example, /home/timh/projects/mywebapp/target/mywebapp-1.2.3), I can do this easily.

 
Prasanna Adh
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello again Tim , according to your suggestion, I'm using short names for directory, E:\Prasanna\Projects\Tomcat\testsite1 for storing my project files.
posting here just before doing it, hope you'll understand, and suggest something,

Creating testsite1.xml whose content would be like this:


Going to copy it in D:\ProgramFiles\Tomcat\conf.....\localhost

will this lead to: http://hostname:8080/testsite1

I'm confused, on context path, you said, The context path will be set to the name of the context file, minus its ".xml" extension

The context path will be set to the name of the context file, minus its ".xml" extension

, is that internal process of Tomcat or I've to set it manually? I've the content as, path="/testsite1", am I doing it correctly? Hoping for your positive response
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, there is one slight pitfall.

If you copied that Context file as D:\ProgramFiles\Tomcat\conf\Catalina\localhost\foobar.xml, then Tomcat would deploy it under the context path http:/hostname:8080/foobar and not http://hostname/testsite1.

That's because for this particular method of deployment, the context pathname comes from the context xml filename and the "path=" attribute will be ignored.

I don't know about you, but I find this rather annoying. But that's the way that Tomcat does it.
 
Prasanna Adh
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ya, foobar is working here also, any way which is the best place to store the external xml file (i.e. testsite1.xml), inside META-INF or WEB-INF, I think it should be kept where visitors can't access them via URL.
 
Tim Holloway
Saloon Keeper
Posts: 27763
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The place to (safely) put a Tomcat Context definition within a WAR is to put it in the WAR's /META-INF/context.xml file. That's the only file location within a WAR that will work.

If you define a Context xml file in TOMCAT_HOME/conf/Catalina/localhost, it will override the META-INF/context.xml file in the WAR. That means that the context.xml file is a good place to store a default configuration, but by using the external Context file instead, you can safely define a Context based on the specific instance of Tomcat that the webapp will be running under. An external Context is also desirable in shops where application developers are not permitted to know the production database passwords and other sensitive information required to configure a production Context. Since application developers are (usually) not permitted to directly read or write files on the production server machine, the product Context cannot be read or modified by them. Or by external application users.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic