Problem: i want to do filter for all webapps.
I created a filter for monitoring requests to the apache tomcat server.
for the sake of example, it's called MyFilter. i created it in netbeans, which created 2 separated directories:
webpages - contains:
META-INF
WEB-INF
index.jsp (a file which i created for viewing monitored data)
source packages
my.package/MyFilter
in the same when i execute it from netbeans, it deploys it and sends me to http://localhost:8080/MyFilter
whenever i view a page under /MyFilter/somepath - it runs the filter.
i want the filter to run on all paths, and not only for the webapp
Where do i need to locate the project files? which project files do i need? should i edit conf/web.xml and add the filter? or should i only be in the specific webapp's web.xml?
EDIT:
i copied the generated .war file into tomcat/webapps
when i start tomcat, it creates a directory (tomcat/webapps/MyFilter/)
i added the filter into tomcat/conf/web.xml. when i start it, it fails to load ://localhost:8080/ but successfully loads (and filters) ://localhost:8080/MyFilter
A filter will by definition only ever run within the web application it is defined in.
You could define it in the web.xml in the conf/ directory of Tomcat to have it included in all web applications deployed to that Tomcat by default (note that you'd also need to make the filter class available to all web applications, probably by putting it in the lib/ directory of Tomcat).
Alternatively, you can implement a Tomcat Valve, which is conceptually similar to a filter, but can be installed on an Engine, Host or Context in Tomcat.
Related
I have added tomcat 7 to my eclipse.
When I start the server it gets started successfully(shows the message in console) but when I hit the URL http://localhost:8080 it says "404 resource not found".
Strange thing is when I go to Tomcat bin directory and start it through start.bat, the same url http://localhost:8080 shows the tomcat homepage in browser without any issue.
Any idea? Help is appreciated.
You need to be aware of two directory trees with Tomcat : TOMCAT_HOME and TOMCAT_BASE.
TOMCAT_HOME contains binary related data and can be shared by many running Tomcat instances (it contains jar, dll, exe and other non-contextual data).
TOMCAT_BASE specifies configuration files (ie catalina.properties, server.xml, context configurations), webapp directories and further files such as specific librairies if required.
When running Tomcat from his installation directory: TOMCAT_HOME and TOMCAT_BASE are set to same location. Then, Tomcat serves ${TOMCAT_HOME}\webapps directory. The special ROOT context let serve the root path and by default contains a simple webapp (browse ${TOMCAT_HOME}\webapps\ROOT for more information).
When running Tomcat from Eclipse, Eclipse will setup two directories:
with editable configuration (generally goes under ${WORKSPACE}\Servers\${SERVER_NAME}-conf)
with deployed files from last describe directory, served context configuration, deployed context and some other working files such as log and work directories.
This last directory generally goes under your workspace metadata but you can edit it from the server editor. And Eclipse uses this directory as TOMCAT_BASE. To this directory, Eclipse doesn't deploy the default ROOT webapp neither other default ones (docs, examples, host-manager and manager). If necessary you can add them from the server configuration directory (first one described).
I've installed Eclipse with web development and during download have installed Tomcat7 to dir E:\Eclipse\tomcat7.
When in Eclipse and trying to test the program I'm getting a realPath of
C:/Users/user/Documents/eclipseJEEWorkspace/javaWebPages/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/org.example.web/WEB-INF/classes/
as my real path and not what I expect which is E:\Eclipse\tomcat7\webapps\org.example.web/WEB-INF/classes/
1) how do I get the real path of the servlet rather than the temporary path...
or am I missing something with how Eclipse uses the installed server? If this is the way then do I have to continuously create the WAR and fiddle around recreating/deleting all the time?
The reason for this is I'm also trying to get a JAVA Servlet getting access to a file in a path higher than webapps. I'm new to servlets....
My development includes third party software that all reference an individual file our.properties so changing the structure is unfortunately not a option.
My directory structure is:
/tomcat
/mycompany
/properties
our.properties //the file we want to access
/*otherfiles
/html
/*not used in this context but to show usage
/javascript
/*not used in this context but to show usage
/webapps
/org.example01.web
/META-INF
/WEB-INF
/org.example02.web
/META-INF
/WEB-INF
/org.example03.web
/META-INF
/WEB-INF
How do I tell my Servlet to access the our.properties file?
I've tried getPath, getResource but without getting the first bit to work, I doubt I'll be getting anywhere fast.
Thanks
When you run Tomcat under Eclipse, via the Tomcat plugin, the webapps path is changed. Eclipse uses .metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/ folder to deploy the project. That's not a temporary path, it's the actual path since your web application is deployed there.
If you run tomcat from command line, or as a service and deploy your web application, you'll see that the path of the servlet will be as you expected.
In order the change the default path to deploy for Eclipse, double click to your Tomcat under Servers view and modify Server locations section.
If I deploy a war file to Tomcat, called for example foo-bar-1.1.2.war, how can I deploy it so that it is extracted to webapps/bar and its URL root is /bar/...?
My intention here is to keep the war file in the webapps server with its version information so that I know which version is installed but have it overwrite a previous version of the app.
I could deploy the war file using PSI Probe. This would allow me to specify a target context for the web app. However, it means that I would lose any version information in the war file name.
Tomcat will always extract the contents of a war file, to a folder of the same name (when it's configured to deploy wars - as default etc.).
You can extract it to a folder name of your choice. So if you unzip the contents of foo.war to a folder called bar/ manually, instead of just dropping the war into the web apps folder, it'll still load the web application.
However, this is totally unnecessary as you can specify the URL pattern of the application without messing with the folder / war file name at all by overriding the context root element for your application:
This is often set in the Tomcat server.xml - but that practice is fairly widely discouraged. Instead, I'd suggest you use context.xml in the META-INF folder of your web application / war file:
<Context path="/bar" .../>
When the application is deployed, the context.xml should be copied to /conf/Catalina/localhost but renamed to foo.xml
Note that conext roots must be unique and there are some additional considerations if you're using the autoDeploy or deployOnStartup operations (Source http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).
Other options include:
Clean the web apps folder each deployment and drop your new foo-1.1.0 war in.
Include the version number in a flat file. foo/version1
Or simply include the version in a config / XML file.
You could also use Ant (or an equivalent tool) to automate your deployments (and perform any of the above).
There is an important point to emphasize about the path attribute of the context fragment definition. To cite the documentation on the topic:
When autoDeploy or deployOnStartup operations are performed by a Host, the name and context path of the web application are derived from the name(s) of the file(s) that define(s) the web application.
deployOnStartup is the default behavior of Tomcat hosts.
To follow the documentation, this has a very important consequence:
the context path may not be defined in a META-INF/context.xml
According to the ways of defining a Tomcat context, this lets only two solutions:
In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory
Inside a Host element in the main conf/server.xml, which is a discouraged solution in a production environment as it requires restarting the server
Another solution takes advantage of the unpackWARs attribute.
In my point of view, for these reasons, the general and easy way to implement a subtle path in a production environment is taking advantage of the naming of war files (what could include versions management and be a solution to your problem). A single sharp (e.g. test#path.war) in the war file names implies a segment in the context path (e.g. /test/path). A double sharp introduces the version number (e.g. test#path##112.war). This works whether or not unpacking war files, hot deployment or not, is deployment agnostic (manager or file system) and manages multiples versions of a same archive.
But if there is the need to have a path distinct from the archive name, it seems the only solution is the descriptor in the /conf/[enginename]/[hostname]/ directory or the server.xml file. For these, you need an access to the server filesystem.
The relevant solution is highly related to the way Tomcat is configured and managed in the everyday.
If you just want to include a version info in your war file name, you can name it like: my-app##1.2.3.war. It gets unpacked to the directory my-app##1.2.3 but the context will be just my-app (i.e. http://host/my-app/).
Works at least with Tomcat 7.0.55
Tomcat documentation (http://tomcat.apache.org/tomcat-6.0-doc/config/context.html)
Only if a context file does not exist for the application in the
$CATALINA_BASE/conf/[enginename]/[hostname]/, in an individual file at
/META-INF/context.xml inside the application files. If the web
application is packaged as a WAR then /META-INF/context.xml will be
copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to
match the application's context path. Once this file exists, it will
not be replaced if a new WAR with a newer /META-INF/context.xml is
placed in the host's appBase.
Text in bold is clear. But I notify as not true. (I need exactly this behaviour)
Here are steps:
aaa.war with context.xml included into META-INF
copy to webapps. tomcat deploys. File conf\Catalina\localhost\aaa.xml OK
change aaa.war by changing META-INF/context.xml
copy to webapps
File conf\Catalina\localhost\aaa.xml is changed!!!
What is wrong? Is it a bug or a hidden feature?
Background - the issue I want to resolve:
Configuration independent build and installation. I plant to ship war file. Client per-configures his Tomcat using his own settings. when I ship a new release I just delivery the war without config and when deployed it will use client specific configuration.
By documentation the best place is the context.xml But if it overwritten each time it make no sense to use at all. (why would I use JNDI and such a things if new deliverable has to created? Changing something in build-time is not a big configuration advantage.)
Environment: windows, tomcat 6.0.33
I've run into the same problem and the documentation is at least inadequate, if not directly misleading.
The problem is, that if you copy a new version of an already deployed WAR file to the webapps directory, Tomcat will not redeploy the existing application but undeploy the old application and then deploy the new application. The difference may first seem insignificant, but the problem is that during undeployment of the old application, any context files in conf/Catalina/localhost are deleted as well. Then, the new context file from the current WAR file will be copied to conf/Catalina/localhost during deployment of the new application.
The only feasible solution I've found is not to deploy the new application as a WAR file, but to replace or overwrite the expanded directory, e.g. not to copy aaa.war to webapps/ but to unpack aaa.war directly into webapps/aaa/.
I have installed and configured tomcat+solr on my personal linux machine and windows as well. I was able to get them working fine. I'm very new to Java and how the file structure works. (i.e. knowing where to put war files and what WEB-INF is) So now that I am ready to install solr and configure it on my clients shared hosting plan, the directions are different from what I did before. I dont want to mess this up and apparently the webserver reboots daily and I dont think I can do it manually which means I have one shot at this every day.
Here is the directions for installing a tomcat servlet on his hosting provider:
http://www.apluskb.com/scripts/Where_do_I_put_my_answer1186.html
As you can see I need to install solr under the html/WEB-INF directory, but read what it says.. its very confusing:
"All Servlets should be uploaded in the /html/WEB-INF/classes directory. Any unpacked custom classes and resources should be uploaded in the /html/WEB-INF/classes directory, while classes and resources packed in Jar files should be uploaded to /html/WEB-INF/lib."
uhh... so which is it? /classes? or /lib? I dont think they explain that very well and I'm a little confused by this statement. Also what exactly do I install? With a normal solr install, solr is put somewhere else, the war file is copied into tomcat and the rest of solr is referenced using some kind of XML configuration file.
Also, since I'm a little new to Java and servlets, can someone explain the tomcat file structure to me (in great detail will definitely get you a +1 from me) and where things should go and why?
Thanks in advance!
Web application structure is defined by J2EE spec, it's not limited (or specific) to Tomcat per se. Here is a detailed tutorial covering its layout. Briefly, however, it's as follows:
There a base (root, home, whatever you want to call it) folder which serves as root of web application, everything else goes under it.
All public stuff (html, images, CSS, javascript, JSP, what have you) goes under that folder (directly or via subfolders).
There's one special folder, also located directly under root, called WEB-INF. It contains non-public stuff, like application descriptor (web.xml), classes (which go into WEB-INF/classes folder), libraries (WEB-INF/lib) and possibly configuration files.
Application can be deployed either using expanded structure above or as WAR (web archive) which is basically an archive containing everything above starting at root folder level (but not including root).
The distinction between classes and lib folders is simple: all packaged libraries (JAR files) need to go into lib; all unpackaged classes (and resource files that need to be in classpath) have to go into classes preserving their directory structure (e.g. com.mypackage.Blah class should go into classes/com/mypackage/)
In your case, it looks like you can only have one web application deployed and it has to be deployed to /html folder. If you're deploying a war file, you need to extract it to that directory (e.g. from within that /html folder run jar xvf solr.war or whatever it's called).