Catch-all host
Hello all, I think I remember seeing something related to this on the list recently, but I just wanted to ask explicitly: Can you set up a catch-all host in Tomcat? If not, could it be made possible, or is there any workaround possible? I'm thinking that an Apache RewriteRule that redirects to /catchall/?url=http://foo.bar.com/test/foo or whatever could work, but it's a bit of a kludge. Calum PS. I'm running Tomcat 6.0.32, but could upgrade if it was in a later version. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7
On 20 June 2011 17:02, Christopher Schultz wrote: > That depends on what Service.logHit does. If it only uses the > HttpServletRequest object during the method's lifetime, then everything > is fine. If it retains a reference to the request object, you will > probably end up with a problem. Oh, just gets the remoteAddr, requestURI, user-agent etc, and logs it to a DB, for example. > Tomcat re-uses the same request and response objects for a long time, > and so multiple request processor threads will see the same object over > the life of the server. If any of that code retains a reference to the > request, by the time the object is re-referenced by the same code for > whatever reason, the object will have "moved on" and will almost > certainly be invalid (from the perspective of the code that cached it) > and might /actually/ be invalid (because it is between requests and > Tomcat has actively invalidated it). I assume that Tomcat won't reuse a request/response until activity on it has ended though? Does it keep a pool of them? Thanks for your help in clarifying this for me, by the way. Calum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Null-pointer exception from response.encodeUrl under Windows Tomcat 7
On 15 June 2011 18:54, Konstantin Kolinko wrote:
> The request and response objects must never be accessed outside the
> request processing cycle. The objects are recycled and cleared or
> reused for subsequent request and responses, and are not guaranteed to
> be thread-safe. The consequences can be severe.
I was interested by this.
So:
private Service service;
@Override
public void init() throws ServletException {
super.init();
service = (Service)
WebApplicationContextUtils.getWebApplicationContext(getServletContext()).getBean("service");
}
protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
service.logHit(request);
}
is a bad thing?
Could you explain why?
I would assume that a new request object is created each time, and
that while something has a reference to it, it will be fine, and when
logHit has finished with it, it will be eligible for garbage
collection.
Calum
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk problem
On 14 June 2011 12:49, Orgil Tulga wrote: > No. I am testing on local domain. I don't understand this. The ajp13 bit in your jkmount.conf needs to refer to a worker in workers.properties. We would need to see it to understand what's happening. This might help you a little? http://tomcat.apache.org/connectors-doc/reference/workers.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk problem
On 14 June 2011 12:28, Orgil Tulga wrote: > My jk connector config is below. > > Below is jk.conf: > > JkWorkersFile /usr/local/jakarta/tomcat/conf/workers.properties Can we see this? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: mod_jk problem
On 14 June 2011 12:07, Orgil Tulga wrote: > Hello All, > > I am using apache and tomcat with mod_jk. > apache version : 2.2.19 > tomcat version : 6.0 > mod_jk version : 1.2.30 > > My web runs through servlet. > > http://domainname:8080/contact.shtml - is working > http://domainname/contact.shtml - is not working > > Why jk connector not converting to servlet? any idea? I imagine people will ask to see your jk config. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: how to correct stop a thread and avoid leaks
On 9 June 2011 09:11, Pid wrote: > Eh? Why would you need to put Tomcat specific dependencies in a spec > compliant Servlet container? The above is simply not true. > > The OP use of a ServletContextListener is perfectly valid, (even if the > rest of the code is a little odd). Is it better to have a separate class that implements the Listener, and sets running = false in the Threads, or just have the thread class implement the listener itself? Or are there not really any pros or cons either way? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: webapp servlet vers web services
On 27 April 2011 18:02, wrote: > > > InitServlet > / > > > If I understand spec correctly and this being the only mapping, it will > become the default and all requests will be routed to the servlet. No - I think it would have to be /* > I also have a bunch of web services which when called do not route to the > servlet. My question; is there something like the idea of serlvet for web > services that will route all requests into a common location and from there > let the application farm it out to the correct web service. The reason I ask > is I like to isolate some security and business logic in to one location and > have that entered first by the web service call and then pass along to > correct service. Yes, you could write a handler which accepted all requests, and then farmed them all out internally based on whatever rules you wrote in the handler? C - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
