Re: static content not served for non-root apps via mod_jk
I remember now why static content works for my ROOT app. I have Apache aliases set-up pointing to specific system directories for all static content. For example, I have all images for the ROOT app aliased here. Alias /img /opt/tomcat7/webapps/ROOT/img Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all But is there a better approach for this so that I don't have to create static content aliases for each new Tomcat app I deploy? I would be stuck using a unique alias for every app which seems crazy. Thanks, Eric 2012/1/13 Eric P : > Hi all, > > I'm having trouble getting Apache to serve static content (jpg, css, js, > etc.) for Tomcat apps via mod_jk for any > application except the ROOT Tomcat app. The ROOT app shows static content > just fine. > > I have the following Apache settings attempting to point *all* requests to > Tomcat and unsetting certain static content > extensions so that Apache will serve them. > > ...clip... > # Send everything to Tomcat > JkMount /* ajp13 > > # And then unsend static content so that httpd will serve it > JkUnMount /*.js ajp13 > JkUnMount /*.css ajp13 > JkUnMount /*.jpg ajp13 > JkUnMount /*.png ajp13 > JkUnMount /*.gif ajp13 > ...clip... > > These settings work for the ROOT Tomcat app but not for anything else > including Tomcat's manager app. > > FYI. when I access via Tomcat's port/web server everything works. > E.g., http://localhost:8080/manager/html > > But not when I access via port 80. > E.g., http://localhost/manager/html > > I"m seeing a 404 Not Found for all static content via port 80/Apache (again, > the only exception is any static content > belonging to the ROOT Tomcat app). I'm experiencing the exact same behavior > on both an Ubuntu and CentOS. > > Thanks for any ideas. > Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
static content not served for non-root apps via mod_jk
Hi all, I'm having trouble getting Apache to serve static content (jpg, css, js, etc.) for Tomcat apps via mod_jk for any application except the ROOT Tomcat app. The ROOT app shows static content just fine. I have the following Apache settings attempting to point *all* requests to Tomcat and unsetting certain static content extensions so that Apache will serve them. ...clip... # Send everything to Tomcat JkMount /* ajp13 # And then unsend static content so that httpd will serve it JkUnMount /*.js ajp13 JkUnMount /*.css ajp13 JkUnMount /*.jpg ajp13 JkUnMount /*.png ajp13 JkUnMount /*.gif ajp13 ...clip... These settings work for the ROOT Tomcat app but not for anything else including Tomcat's manager app. FYI. when I access via Tomcat's port/web server everything works. E.g., http://localhost:8080/manager/html But not when I access via port 80. E.g., http://localhost/manager/html I"m seeing a 404 Not Found for all static content via port 80/Apache (again, the only exception is any static content belonging to the ROOT Tomcat app). I'm experiencing the exact same behavior on both an Ubuntu and CentOS. Thanks for any ideas. Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fire off asynch task in Tomcat.
Christopher Schultz wrote: > Oh, and one more thing: any in-memory solution you come up with (that is, without writing to a database) is likely to suffer from loss of jobs in the event of a crash or poorly-coded exception-handling. This isn't necessarily a case for using a separate process just for sending emails, but definitely a case for writing your "job" to the database synchronously during the request so that you're sure it was written. Thanks everyone for all your excellent ideas. I duly read all of them (*grin*). I'll probably go w/the email queue/database table approach. All the points André and Christopher raised gave me further insight into the robustness of this approach (loose coupling w/the app, no extra lib dependencies, emails not lost if the app goes down, etc.). Also, the email queue table can serve as a nice log of emails processed. Anyway, you all were super helpful. Thanks again! Eric P. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Fire off asynch task in Tomcat.
Hi all, In my Tomcat app I'm looking for a good (or commonly used) method for firing off an asynchronous task. For example, a user registers for an account, and an a task to send a verification email to the user is triggered w/o delaying the response to the user (i.e., task happens in the background). I'm somewhat aware that JMS could be used for this and is part of most J2E environments, but I'd like to see if there's some way to pull this off w/vanilla Tomcat. I had a couple ideas that would probably work, but I'd like to see how others have solved this problem. One idea would be to insert a record into a database table that signifies an email should be sent to the user. This table could be regularly checked by a scheduled job (e.g., a TimerTask) that runs every minute in the background. Another (maybe not so good) idea would be to leverage perhaps a session or request attribute listener that would check for a certain attribute being added to a session or requests. Then if a 'send email' attribute comes through, the listener could process an email. This seems like a bad idea though as I believe the listener event class would be triggered incessantly any time attributes are added/removed when in fact I'm only actually interested in the 'send email' attribute. Anyway, I'm open to all ideas and appreciate you indulging me this far. Eric P. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Application" vars -
So it makes sense to go into what "disruption" means. I'm not 100% sure about the following, it would be good if a tomcat heavyweight would confirm/refute what I say. When you initiate a webapp reload, Tomcat waits for requests that have already started processing to terminate. This ensures that people who accessed your app just before the webapp get a complete response. Once that's done, the application is reloaded and your servlets' init methods are called if necessary. During this time, incoming requests aren't denied, they are just paused until the reload is complete. So the only disruption people see is your application freezing up for the time it takes to reload (which is going to depend on what you your initialization consists of). No ugly server unavailable errors or anything of the sort. If you don't like the idea of your app freezing, think about this. Rereading environment params without reloading has its own risks, namely potential race conditions. Imagine you have 5 parameters, and requests are coming in as you are reading these in and initializing your webapp. A request might be handled while 2 params have been read, but 3 still contain the old values. If you start to think about locking/synchronization to solve this you're definitely better off just using Tomcat's reload mechanism. So my answer would be, trust Tomcat's reloading process unless you absolutely want to avoid your webapp freezing for the time it will take for it to init (this depends on the webapp). If you want to do your own "reloading", think long and hard about potential race conditions (which will occur in all except the simplest cases). Again, all this should probably be verified, you can set up very simple test cases with a JSP that sleeps, etc. Shay, I think you made a good case for keeping app vars in web.xml (i.e., seems pretty apparent now that's where they belong). Thanks for taking the time to respond. I sincerely appreciate it! Eric P. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "Application" vars -
Shay, Forgive all potential newbness in my responses below. I'm still learning this stuff. Shay Rojansky wrote: Hi Eric. Would making your servlet reload all application vars not be akin to simply reloading your servlet altogether, by changing context/init params in your web.xml or context.xml? Do you mean "reloading your 'application' altogether"? If so wouldn't that cause disruption to users currently on the app? This disruption is what I'd like to avoid. If you really want to avoid an application reload, why not just have your app read its values from a properties config file instead of a DB? It would be much more lightweight and standard. That's an idea. But wouldn't file I/O every time a servlet needs an application value be way more expensive than storing settings in a record, reading and setting them to the application scope once, and only resetting these vars manually when needed? Is this standard documented somewhere? Thanks... I appreciate the ideas. Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
"Application" vars -
I've been loading up my web.xml with context and init params for my first app, but I'm thinking at some point it'd be nice to tweak these values on the fly while the app is running. What are some good practices to accomplish this? I'm leaning towards storing all application variables in a database table w/one record, and loading these values into the application scope w/a servlet on app startup. Then if I need to tweak any values I could update the db record and hit this servlet to reload all the application scope vars. I'm guessing there's some other possibly better ways to go about this. Thanks for reading, Eric P. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Where to store uploaded user content in app
Caldarale, Charles R wrote: From: Eric P [mailto:eric.maill...@gmail.com] Subject: Where to store uploaded user content in app For example, in my application I was thinking I would create an empty directory under /web/WEB-INF for the non-web accessible image uploads and another empty directory right under /web for the web accessible images. Bad idea. You should treat the deployment area as read-only, at least from the webapp's perspective. To be spec compliant, you can't even assume that the deployment area is part of the platform's file system. Better to locate the necessary directories completely outside of Tomcat's directory structure, and provide system or properties to tell the webapp where to find them. As far as serving the moderated images, it's easy to define a simple -only webapp for that location, and let Tomcat's DefaultServlet deliver the pictures. Just create a element with a docBase attribute pointing to the approved image directory, and put the element in conf/Catalina/[host]/[imageURL].xml; no other structure or configuration is needed. - Chuck Perfect. This is exactly the kind of answer I was looking for. Thanks, Chuck! Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Where to store uploaded user content in app
Hi ya, I have an application that I want to write that would allow users to upload an image to somewhere non-web accessible and said image is then later moved somewhere web accessible (after image moderation). For example, in my application I was thinking I would create an empty directory under /web/WEB-INF for the non-web accessible image uploads and another empty directory right under /web for the web accessible images. I'm not totally familiar w/Tomcat's redeploy process, but is it a safe/normal practice to create empty directories in your app like this w/o the fear of losing anything when the app is redeployed in production? Are there better/safer places to put user content for these circumstances? Thanks for any ideas, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Virtual host set-up woes
$CATALINA_HOME/conf/Catalina/dummyapps/ROOT.xml Where did you get that location for a element? It certainly didn't come from the docs, nor from Peter's or my messages. Go back and reread them all. To quote from Peter's message: Yep, I had that wrong. I was getting the name and appBase confused. create a file in $tomcathome/conf/Catalina/yourhost called ROOT.xml The name of your is? (It's certainly not dummyapps.) Tomcat would have completely ignored a file in the above location. WEB-INF/web.xml Does that look at all like the element Peter provided? To refresh your memory, here it is again (with the invalid path attribute removed): Note the presence of the docBase attribute and the comment therein. Also, it's pointless to have a of WEB-INF/web.xml in your element, since that value is already in the global one. If you have nothing to put in a element, you don't need one. Removed. Now I realize the global nature of the context.xml file that lives in /conf. And the directory structure for the new context home (the content a built/deployed app I copied over from its old location in /webapps). $CATALINA_HOME/dummyapps $CATALINA_HOME/dummyapps/WEB-INF $CATALINA_HOME/dummyapps/index.jsp $CATALINA_HOME/dummyapps/(other static files) Which is still very wrong. The appBase directory is the default location for all of a 's webapps - there can be many. The default webapp for a must be named ROOT (case sensitive), and is located either under the appBase directory, or where the docBase attribute points in the conf/Catalina/[host]/ROOT.xml file. Peter's message shows one way to achieve what you want, and facilitates the use of the same .war file or directory as the default one for each (the docBase attribute of all the ROOT.xml files would point to the same place). If in fact you want to use a different default webapp for each , you can separate them by the appBase setting of each , and not place the ROOT.xml file in conf/Catalina/[host]. In this scenario, your structure would be: host1apps/ROOT/ host1apps/ROOT/WEB-INF/ host1apps/ROOT/WEB-INF/lib/ host1apps/ROOT/WEB-INF/classes/ host1apps/ROOT/WEB-INF/web.xml host1apps/ROOT/META-INF/ host1apps/ROOT/META-INF/context.xml host1apps/ROOT/index.jsp host1apps/ROOT/ I think this is what helped out the most. I never totally understood that I could use the ROOT context in this manner (which is exactly what I was after). Thanks for your helpful and detailed responses. Thanks to Peter and Hassan as well. I have the virtual host working now! Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Virtual host set-up woes
Caldarale, Charles R wrote: From: Peter McNeil [mailto:pe...@mcneils.net] Subject: Re: Virtual host set-up woes 1. edit conf/server.xml and add a section inside the tag that looks like this:- 2. create a directory inside your tomcat home directory called "yourhostapps" as defined above e.g. mkdir $tomcathome/yourhostapps Note that the above needs to be repeated for each desired host. 4. create a file in $tomcathome/conf/Catalina/yourhost called ROOT.xml, making sure ROOT is all upper case, that contains the context for your app e.g. You were good up to that point. The path attribute is not allowed here; remove it. The other point is that each name must have a DNS entry or else your clients will never be able to reach it. (Alternatively, you could require your clients to make entries in their hosts files - assuming your clients can find it.) - Chuck (Keep getting a high spam score; added some spaces in between URLs; resending to list) Ok... I think I'm getting closer. Now when I go to http:// dummy. com:8180 (8180 is the port I'm running the connector on), I get a completely blank page. However, I am able to access/display certain static content for example: http:// dummy. com:8180/css/main.css local file: $CATALINA_HOME/dummyapps/css/main.css But I only get an blank page for a simple index.jsp file (file is simple HTML markup w/some text). View source from the browser shows absolutely nothing. http:// dummy. com:8180/index.jsp local file: $CATALINA_HOME/dummyapps/index.jsp And a blank page is all I get for a simple static HTML file that lives in the same place. http:// dummy. com:8180/index.html local file: $CATALINA_HOME/dummyapps/index.html In fact even any non-existing file produces a blank page (i.e., no error; just blank; nothing in the logs). E.g., http:// dummy. com:8180/non-existent-file.dummy Here are the changes I'm employed based on Peter and Charles' comments and another read of the official docs. $CATALINA_HOME/conf/server.xml ... ... suffix=".log" timestamp="true"/> ... ... /etc/hosts 127.0.0.1 localhost dummy. com ... $CATALINA_HOME/conf/Catalina/dummyapps/ROOT.xml WEB-INF/web.xml And the directory structure for the new context home (the content a built/deployed app I copied over from its old location in /webapps). $CATALINA_HOME/dummyapps $CATALINA_HOME/dummyapps/WEB-INF $CATALINA_HOME/dummyapps/index.jsp $CATALINA_HOME/dummyapps/(other static files) ... Nothing of interest in any of the logs. Thanks for reading all of this. Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Virtual host set-up woes
I'm struggling big time trying to set up a virtual host in Tomcat. I'm running Tomcat version 6.0.18 under Linux and nothing else (i.e., no Apache web server, etc.). I've read the official 6.0 docs here over and over. http://tomcat.apache.org/tomcat-6.0-doc/virtual-hosting-howto.html But it seems like these docs are trying to give me a whole new context where I can put more webapps (maybe I'm missing the point), but I merely want to be able to point my browser at something arbitrary like www.dummy.com (or www.dummy.com:8080) and have an app deployed under /webapps/dummy be served w/o the need to add /dummy to the end of the URL. Can anyone give point me to simple instructions for setting this up? Thanks and sorry for being so pathetic. I've read probably a dozen forum posts and articles (and tried about ~30 different configurations in server.xml) but nothing has worked for me. Also, it seems like the way to set this up under 6.* has changed a bit. After going back and forth between including a and omitting it (the 6.* way?) I'm absolutely confused. Thanks for reading! Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: debugging model classes tied to Tomcat datasources
> I'll bet the only thing your code does with a JNDI string is perform the lookup and get a Datasource. You could implement multiple constructors allowing your code to be initialized w/ a JNDI string, DataSource object, or url/username/password. The code utilizing the model classes would simply create them using which ever constructor it has data for. --David David, Sorry for the late reply (this darn this called "life" keeps butting in). This approach is working for me; thanks for offering it. Charles & Mark, thank for your responses as well. Sincerely, Eric - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
debugging model classes tied to Tomcat datasources
Hi, (Tomcat newb alert) I've got a simple database servlet application that has a few model classes on the back end. I have the model classes pretty well genericized so that they could (almost) be utilized outside of Tomcat by another app, but they do utilize the Tomcat data sources I've set up (via an InitialContext data source lookup). So this makes it impossible (?) to execute the model classes outside of Tomcat. Does anyone have any suggestions about how they would approach this problem so that they could debug and/or utilize these model classes that rely on database access? Thanks for reading. I'm open to any/all ideas. Eric P. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
