You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Justin Case <se...@yahoo.com> on 2010/12/01 15:22:01 UTC
automatic deployment without server.xml - bad request
Hello all,
I'm on Tomcat 6.0.29 in Windows (XP or server 2003, same) and I'm trying to get
an application to deploy automatically without putting it in server.xml - as the
documentation strongly recommends.
Just to note, if I put the context setting in server.xml like this all works
fine.
<Host appBase="wtpwebapps" autoDeploy="false"
deployOnStartup="false"
name="localhost" unpackWARs="true" xmlNamespaceAware="false"
xmlValidation="false">
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" pattern="common" prefix="access_log."
resolveHosts="false" suffix=".txt" />
<Context docBase="com.mycompany.myapp" path="/myapp"
reloadable="true" override="true">
<Manager pathname="" />
<Resource name="hibernate/MySessionFactory" auth="Container"
type="org.hibernate.SessionFactory"
factory="com.mycompany.myapp.HibernateSessionFactoryTomcatFactory"
configuration="hibernate.cfg.xml" />
</Context>
</Host>
If I remove the context from server.xml and place a context.xml in my app's
META-INF, then enable the two deploy params, the deployment happens succesfully
- that's what the console says at least. The application even starts ok, I can
see the logging of my classes.
BUT!
Each request to the application will throw immediately a HTTP error 400 - bad
request. Funny enough, this error will not even be logged anywhere, even when I
enabled debug logging in Tomcat! (and got 100M of logs which I searched
through). No record of the 400 whatsoever, while I can confirm the Host header
IS there - I see it in Firebug (and with the other context it works anyway).
What I see different is that the Tomcat's work directory, the
work/Catalina/localhost/com.mycomp.myapp directory it created automatically at
startup is and stays EMPTY. Now normally there should be the compiled JSP's
right? So there's SOMETHING not ok about this automatic deployment, and I'm
unable to figure out what it is. There was in May an interesting discussion
thread on this list called "Misunderstanding deployOnStartup actions", but that
guy also ended up using server.xml so... I only see advice like "your config is
wrong to start with", which might be very true (otherwise one wouldn't be
posting), but I wasn't able to see anywhere sampled a CORRECT config.
Thanks A LOT for any hints/samples/links,
JC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: automatic deployment without server.xml - bad request
Posted by Justin Case <se...@yahoo.com>.
> From: Markus Schönhaber <to...@list-post.mks-mail.de>
>
> Yes, it is an error. But in this case, I, too, consider the error erroneous.
> A status code of 400 basically means that the request was syntactically
> b0rked. But, as I understand it, that's not the problem here: the
> request is syntactically fine - it fails because the server is
> misconfigured. Therefore a status code of 500 seems more appropriate to me.
Well, w3.org says:
"Error 4xx, 5xx
The 4xx codes are intended for cases in which the client seems to have erred,
and the 5xx codes for the cases in which the server is aware that the server has
erred. It is impossible to distinguish these cases in general, so the difference
is only informational.
The body section may contain a document describing the error in human readable
form.
Not found 404: The server has not found anything matching the URI given
Internal Error 500: The server encountered an unexpected condition which
prevented it from fulfilling the request."
I still vote for 404 :) (as if my vote matters) because the server is all fine
and dandy (the APP is misconfigured not the server), but the client is asking
for something not available. But the difference is only informational :)
Cheers,
JC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: automatic deployment without server.xml - bad request
Posted by Markus Schönhaber <to...@list-post.mks-mail.de>.
02.12.2010 20:44, Pid:
> On 12/2/10 12:34 PM, Justin Case wrote:
>>> From: Pid <pi...@pidster.com>
>>> If the request isn't being routed to your application, then without a
>>> ROOT application the host hasn't got a mechanism to serve any response
>>> other than an error.
>>
>> Error is fine, as long it's a 404 (and not this enigmatic 400)...
>
> 400 isn't enigmatic and /is/ an error. ;)
Yes, it is an error. But in this case, I, too, consider the error erroneous.
A status code of 400 basically means that the request was syntactically
b0rked. But, as I understand it, that's not the problem here: the
request is syntactically fine - it fails because the server is
misconfigured. Therefore a status code of 500 seems more appropriate to me.
--
Regards
mks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: automatic deployment without server.xml - bad request
Posted by Pid <pi...@pidster.com>.
On 12/2/10 11:39 PM, Justin Case wrote:
> But what do you think about the 400
> error? Is it really appropriate as answer in this setup?
Well, 404 might be appropriate from the client's point of view.
I think I remember the recent suggestion of a default ROOT application,
used when no other is present, which would prevent this from actually
being a problem, it seems like a good idea to me.
p
RE: automatic deployment without server.xml - bad request
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Justin Case [mailto:send_lotsa_spam_here@yahoo.com]
> Subject: Re: automatic deployment without server.xml - bad request
> ...or maybe I should consider whether my application can be
> both root AND answer to the context...
Really, you *must* have a default webapp. Why don't you just deploy your webapp as ROOT and be done with it? Don't make life difficult for yourself.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: automatic deployment without server.xml - bad request
Posted by Justin Case <se...@yahoo.com>.
> From: Pid <pi...@pidster.com>
>
> On 12/2/10 10:24 PM, Justin Case wrote:
> > Yeah I probably will do that - but I will still regard it as a dirty
hack...
>
> A ROOT app should be mandatory.
It's not - yet :) so I'm all legal without. But what do you think about the 400
error? Is it really appropriate as answer in this setup? And is it really my
particular need to write an application only to convert the 400 into 404? I'm
just surprised...
...or maybe I should consider whether my application can be both root AND answer
to the context...
Cheers,
JC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: automatic deployment without server.xml - bad request
Posted by Pid <pi...@pidster.com>.
On 12/2/10 10:24 PM, Justin Case wrote:
> Yeah I probably will do that - but I will still regard it as a dirty hack...
A ROOT app should be mandatory.
p
Re: automatic deployment without server.xml - bad request
Posted by Justin Case <se...@yahoo.com>.
> From: Pid <pi...@pidster.com>
>
> On 12/2/10 12:34 PM, Justin Case wrote:
> > Error is fine, as long it's a 404 (and not this enigmatic 400)...
>
> 400 isn't enigmatic and /is/ an error. ;)
It IS an error indeed, but we're not talking about throwing just ANY random
error number here :)
400 is a specific error which to my untrained eye has absolutely nothing to do
with the fact that under the named context there's no application deployed.
That's why a 404 would have sent me much sooner in the right direction -
resource not found, instead of trying endlessly to play with the request headers
and the HTTP protocol details. But maybe it's just me.
> I'd suggest you make a simple empty ROOT app. Tomcat will then serve
> 404s for missing URLs. You could also customise the 404 response page
> to suit.
Yeah I probably will do that - but I will still regard it as a dirty hack...
Otherwise thanks a lot for your support, I was obviously misunderstanding what
the Path parameter of the Context is expected to do. Now I know what I have to
change. Or I think so at least. Back to the drawing board.
Thanks a lot to you all gals/guys,
JC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: automatic deployment without server.xml - bad request
Posted by Pid <pi...@pidster.com>.
On 12/2/10 12:34 PM, Justin Case wrote:
>> From: Pid <pi...@pidster.com>
>> If the request isn't being routed to your application, then without a
>> ROOT application the host hasn't got a mechanism to serve any response
>> other than an error.
>
> Error is fine, as long it's a 404 (and not this enigmatic 400)...
400 isn't enigmatic and /is/ an error. ;)
You can either implement a custom ErrorValve in your host, or provide a
ROOT application. Any request to your server that doesn't match the
path of a deployed application gets directed to ROOT. Which you don't have.
I'd suggest you make a simple empty ROOT app. Tomcat will then serve
404s for missing URLs. You could also customise the 404 response page
to suit.
p
Re: automatic deployment without server.xml - bad request
Posted by Justin Case <se...@yahoo.com>.
> From: Pid <pi...@pidster.com>
> If the request isn't being routed to your application, then without a
> ROOT application the host hasn't got a mechanism to serve any response
> other than an error.
Error is fine, as long it's a 404 (and not this enigmatic 400)...
Thank you,
JC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: automatic deployment without server.xml - bad request
Posted by Pid <pi...@pidster.com>.
On 12/2/10 10:00 AM, Justin Case wrote:
>> From: Konstantin Kolinko <kn...@gmail.com>
>
>>
>> Just curious: why wtpwebapps? Eclipse IDE uses that name.
>
> Precisely :) Only because Eclipse publishes it there, so the name was kept. No
> other reason.
>
>> Try with recent 6.0.x (build it yourself), or 6.0.30 (when it comes
>> out), or 7.0.5 -- they will log such requests into AccessLog.
>> Usually it means that this request was rejected by the connector, or
>> by CoyoteAdapter. What is your client?
>
> Ummm, I wouldn't go into beta stuff... I have enough troubles as you can see :)
> and what do you mean by "client"? The browser?
>
>> Do you have a ROOT application deployed? You should have one.
>
> This is true, I don't have one. Might this be The/a problem?
If the request isn't being routed to your application, then without a
ROOT application the host hasn't got a mechanism to serve any response
other than an error.
p
Re: automatic deployment without server.xml - bad request
Posted by Justin Case <se...@yahoo.com>.
> From: Konstantin Kolinko <kn...@gmail.com>
>
> Just curious: why wtpwebapps? Eclipse IDE uses that name.
Precisely :) Only because Eclipse publishes it there, so the name was kept. No
other reason.
> Try with recent 6.0.x (build it yourself), or 6.0.30 (when it comes
> out), or 7.0.5 -- they will log such requests into AccessLog.
> Usually it means that this request was rejected by the connector, or
> by CoyoteAdapter. What is your client?
Ummm, I wouldn't go into beta stuff... I have enough troubles as you can see :)
and what do you mean by "client"? The browser?
> Do you have a ROOT application deployed? You should have one.
This is true, I don't have one. Might this be The/a problem?
Thanks a lot,
JC
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: automatic deployment without server.xml - bad request
Posted by Konstantin Kolinko <kn...@gmail.com>.
2010/12/1 Justin Case <se...@yahoo.com>:
>
> <Host appBase="wtpwebapps" autoDeploy="false"
Just curious: why wtpwebapps? Eclipse IDE uses that name.
> deployOnStartup="false"
> name="localhost" unpackWARs="true" xmlNamespaceAware="false"
> xmlValidation="false">
> <Valve className="org.apache.catalina.valves.AccessLogValve"
> directory="logs" pattern="common" prefix="access_log."
> resolveHosts="false" suffix=".txt" />
> <Context docBase="com.mycompany.myapp" path="/myapp"
> reloadable="true" override="true">
> <Manager pathname="" />
> <Resource name="hibernate/MySessionFactory" auth="Container"
> type="org.hibernate.SessionFactory"
>
> factory="com.mycompany.myapp.HibernateSessionFactoryTomcatFactory"
> configuration="hibernate.cfg.xml" />
> </Context>
> </Host>
>
> If I remove the context from server.xml and place a context.xml in my app's
> META-INF, then enable the two deploy params, the deployment happens succesfully
> - that's what the console says at least. The application even starts ok, I can
> see the logging of my classes.
> BUT!
> Each request to the application will throw immediately a HTTP error 400 - bad
> request.
Try with recent 6.0.x (build it yourself), or 6.0.30 (when it comes
out), or 7.0.5 -- they will log such requests into AccessLog.
Usually it means that this request was rejected by the connector, or
by CoyoteAdapter. What is your client?
Do you have a ROOT application deployed? You should have one.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org