help migrating
I am migrating from 6.0.20 on FreeBSD 8-RELEASE (i386) where everything works fine to 6.0.26 on Gentoo (unknown ditro version) Linux (kernel version 2.6.32.9) where everything works but some of my servlets can't load some of the classes they call. For example: java.lang.NoClassDefFoundError: backend/rci2/namespaces/def/InfiniteGlue$1 java.lang.Class.getDeclaredMethods0(Native Method) java.lang.Class.privateGetDeclaredMethods(Class.java:2427) java.lang.Class.getMethod0(Class.java:2670) java.lang.Class.getMethod(Class.java:1603) java.lang.Class.getEnumConstantsShared(Class.java:2934) java.lang.Class.enumConstantDirectory(Class.java:2963) java.lang.Enum.valueOf(Enum.java:191) backend.rci2.NamespaceWalker.parseChildNamespace(NamespaceWalker.java:187) There has been no change in the servlet code base and/or the instance install dir (I am using virtual hosting)... to be clear again all static content works and servlets partially work (tomcat can find them but somehow the classpath or soemthing is screwy) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: help migrating
Compare the directory listings for: /path/to/tomcat/lib for each installation and check that they match, ie have the same jar files. Then compare the lib dir in the deployed app in each server: /path/to/tomcat/webapps/myapp/WEB-INF/lib If that doesn't produce any joy, you might need to compare the WEB-INF/classes directories too. Except for using WEB-INF/classes and not lib I checked and they are the same (comarped by diff'ing the output of find . even the xxx.xxx$[some number].class are the same)... I do not define an AppBase but a DocBase only in server.xml does that matter... also on machine I am migrating from /home is symlinked to /usr/home but it is a real dir (not a symlink) on the machine I am migrating to... also I am using JDK 1.6u3 on the one I am moving to and 1.6u17 on the one I am moving to) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: help migrating
I found the problem... there was a missing quote in the compile script for the project - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 1:51 AM, Aryeh M. Friedman wrote: Yes we are and thats why I probably mistook the effect of it doing that as a side effect instead of a designed in feature... now that being said we have used that content day since the first few lines of our code was written and until this post (about 2 years) the servlet getting getParameter via GET *AND* POST was not an issue... but for some reason a new client side request format (which there is no easy way around not using) messed it up. Ok, so what's next? Sometimes you are getting a null when you expect data, right? Well, are you only getting null when the request is a GET? POST? Or is it something else? It gets null's on POST's only but only from the new input format (there are parts of the app that still use the old format and they work fine) If you wanted to get cute, you could implement this one-parameter-to-rule-them-all strategy as a Filter which wraps the I will consider that as a future refactoring - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 2:20 PM, Aryeh M. Friedman wrote: It gets null's on POST's only but only from the new input format (there are parts of the app that still use the old format and they work fine) Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote: Christopher Schultz wrote: Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) Hmm. So, POST + application/x-www-form-urlencoded yields a null parameter with your new payload? I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. The client does url encode in addition to translating any chars that are used either by tomcat and/or or app to decode the reaquest (namely = is translated to ^, comma to #, right/left parens to @ and $ respectivally) then I use javascripts escape(string) method to url encode it the app by default uses post but if I cut and paste the resulting payload into a GET and pass it to the app it works fine (i.e. the app uses POST but I do manual testing with GET) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Aryeh M. Friedman wrote: Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote: Christopher Schultz wrote: Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) Hmm. So, POST + application/x-www-form-urlencoded yields a null parameter with your new payload? I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. The client does url encode in addition to translating any chars that are used either by tomcat and/or or app to decode the reaquest (namely = is translated to ^, comma to #, right/left parens to @ and $ respectivally) then I use javascripts escape(string) method to url encode it the app by default uses post but if I cut and paste the resulting payload into a GET and pass it to the app it works fine (i.e. the app uses POST but I do manual testing with GET) opps forgot to mention the manual test works for both the new and old format but the automated method only works for the old format (both formats use the one param to rule them all strategy) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 3:48 PM, Aryeh M. Friedman wrote: Christopher Schultz wrote: Is this a new client, or just a new data format? Mark's suggestion that you may be using POST without the proper Content-Type would result in getting null for this parameter (because Tomcat will not parse it for you). If this is the case, you should either fix the new client to use the proper Content-Type, or fall-back to reading and parsing the request body manually when these requirements are not met. New format same frontend client code which does use the proper content type. (the content type is defined at a lower level then the format and that code has not changed [using firebug on firefox confirms that fact]) Hmm. So, POST + application/x-www-form-urlencoded yields a null parameter with your new payload? I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNe+AACgkQ9CaO5/Lv0PArcwCdHf9ddwqWTKkoYb0jA9BHDs+/ LUoAnj6gNWY5mdPoCAxmgfKceWxSBy6r =wn5q -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Also forgot to mention I already refactored the servlet to use pure hex encoding (namely we convert the entire request into a hex string so for example a old format message of call=default.Session.getSession() gets translated into 63616c6c3d64656661756c742e53657373696f6e2e67657453657373696f6e2829 which the servlet then decodes and then does it own parsing (in both formats the call param [our does it all param] has roughly the format above [i.e. a psedo method call like format])... by new format I only mean we got a query string that exceeds 1k for the first time - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh, On 3/2/2010 4:05 PM, Aryeh M. Friedman wrote: Aryeh M. Friedman wrote: Aryeh M. Friedman wrote: Christopher Schultz wrote: I know this sounds silly, but we're getting down to the grasping-at-straws level, here, so bear with me: have you checked to see that your request body is actually in the correct format (that is, urlencoded, etc.)? I haven't looked at the Tomcat code, but Tomcat might give up if the request body is not parsable. Have you tried calling request.getInputStream and dumping the request body when the parameter is null? That might give you some indication of what's happening. The client does url encode in addition to translating any chars that are used either by tomcat and/or or app to decode the reaquest (namely = is translated to ^, comma to #, right/left parens to @ and $ respectivally) then I use javascripts escape(string) method to url encode it the app by default uses post but if I cut and paste the resulting payload into a GET and pass it to the app it works fine (i.e. the app uses POST but I do manual testing with GET) Wait, what? Why all that extra encoding? Well, I guess you know what you're doing. opps forgot to mention the manual test works for both the new and old format but the automated method only works for the old format (both formats use the one param to rule them all strategy) Obviously, something is different. Check everything between your manual and automated tests and see what is different. Maybe it's a trailing newline. Maybe it's a Content-Length header. Whatever it is, apparently, it's significant. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuNl08ACgkQ9CaO5/Lv0PDBlgCgsgeTljstZhft+VK0ail2xfPC hWsAnje2YQ7OMKt3u6bjfBT6z5zSXTs8 =gh1k -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org The above issues is why we switched to the hex encoding scheme - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Aryeh,
On 3/2/2010 4:12 PM, Aryeh M. Friedman wrote:
Also forgot to mention I already refactored the servlet to use pure
hex encoding (namely we convert the entire request into a hex string
so for example a old format message of
call=default.Session.getSession() gets translated into
63616c6c3d64656661756c742e53657373696f6e2e67657453657373696f6e2829
If that string above is your entire POST request body, then it's not
properly formatted. Instead, it should be:
call=8347812459870132405987234985023450987
or whatever. The parameter has to have a name :)
Design decision for two reasons:
1. If we are already decoding the request from hex to plain text
mightiest use getReader()
2. Our app needs to support several frontends (not just the web via a
servlet)
Just for reference here is the refactored servlet with any trade secret
code removed (all the tomcat--servlet logic is kept)
// src/backend/servlet/Servlet.java
package backend.servlet;
import java.io.IOException;
import java.io.PrintWriter;
import java.io.Reader;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import backend.util.StringUtil; // hex encoding/decoding
public class Servlet extends HttpServlet
{
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException
{
handleRequest(request,response);
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws IOException
{
handleRequest(request,response);
}
private void handleRequest(HttpServletRequest request,
HttpServletResponse response)
throws IOException
{
// not possible to do custom error reporting yet
because we have no writer to write to
PrintWriter pw=new PrintWriter(response.getWriter());
String call=null;
try {
call=StringUtil.hexToString(
readRequest(request)).substring(5);
} catch(IOException e) {
write out error in custom format
}
code to do something with the request
}
private String readRequest(HttpServletRequest request)
throws IOException
{
if(request.getMethod().equals(GET))
return request.getQueryString();
String out=;
Reader reader=request.getReader();
// reading all the content in one read causes problems
sometimes so we read it char by char
for(int i=0;irequest.getContentLength();i++)
out+=(char) reader.read();
return out;
}
private static final long serialVersionUID=0L;
}
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Pid wrote:
On 28/02/2010 02:00, Aryeh M. Friedman wrote:
I am refactoring a servlet we have used successfully for several years
now to accommodate input that does not amen itself to
HttpServletRequest.getParameter()... The only way it seems to be to
handle our particular input (the nature/format of the input is covered
by an NDA so I can not discuss it in any detail) read the raw
request in the old servlet HttpServletRequest.getParameter() had a
nice side effect that we where able to do something like this:
I don't understand, can you explain what you mean by a side effect?
See below for details but it appears sun's general servlet api model is
designed to treat each request method differently and getParameter (at
least how I am using it) is a short-circuit of this model.
public void doGet(HttpServletRequest request,HttpServletResponse
response)
throws IOException
{
handleRequest(request,response);
}
public void doPost(HttpServletRequest request,HttpServletResponse
response)
throws IOException
{
handleRequest(request,response);
}
private void handleRequest(HttpServletRequest
request,HttpServletResponse response)
{
String input=Request.getParameter(foo); // we are only interested in
this one param
Request or request - is this a typo?
thats what I get for writting sample code for a post only and not
actually compiling it ;-)
process input
}
I want to preserve the single handler design but since getParameter
barfs on our new input format and there is no unified raw input reader
the only thing I can think of is make it so doGet and doPost use
request.getQueryString() and request.getReader() respectivally... is
there an easier way? (namely I want to keep doXXX as pure wrappers with
nothing but a dispatch to handleRequest()).
Why does request.getParameter() not work, or is that a secret?
I am not actually sure because the input is properly URL encoded and
works if sent as a GET but fails (getParameter returns null) if done as
a POST (note every other input sent to this servlet in the past did work
with both GET and POST) the reason for only caring about one
parameter for all input is a trade secret though that being said for
other reasons beyond (that are also trade secrets) the failed
getParameter call we decided to rewrite the servlet so it's entire
payload data is a hex encoded string and thus the need for reading the
raw request instead of using getParameter. I suspect it is because
we had some funky character encoding (UTF-8 but some characters could be
parsed in more then one way with the context not giving enough clues to
which one was correct) [this was why we switched to hex encoding]
Is request.getInputStream() not suitable?
I thought thats what I was asking ;-) namely getReader() and
getInputStream() only work if it was a POST (if GET we need to use
getQueryString())
As far as I can see, there's absolutely no reason that handleRequest
won't continue to work, as long as the code inside actually does work.
I thought so also until I traced the bug to the very first line of
handleRequest when it used getParameter (i.e. disagreement on output of
the call depending on request method)
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: unified doXXX()
Mark Thomas wrote: On 01/03/2010 08:01, Aryeh M. Friedman wrote: Pid wrote: I want to preserve the single handler design but since getParameter barfs on our new input format and there is no unified raw input reader the only thing I can think of is make it so doGet and doPost use request.getQueryString() and request.getReader() respectivally... is there an easier way? (namely I want to keep doXXX as pure wrappers with nothing but a dispatch to handleRequest()). Why does request.getParameter() not work, or is that a secret? Take a look at SRV.3.1 in the servlet spec. Are you sure you are using application/x-www-form-urlencoded with your POST? If you use that content type, Tomcat will merge parameters in the POST body and the query string. Yes we are and thats why I probably mistook the effect of it doing that as a side effect instead of a designed in feature... now that being said we have used that content day since the first few lines of our code was written and until this post (about 2 years) the servlet getting getParameter via GET *AND* POST was not an issue... but for some reason a new client side request format (which there is no easy way around not using) messed it up. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
unified doXXX()
I am refactoring a servlet we have used successfully for several years
now to accommodate input that does not amen itself to
HttpServletRequest.getParameter()... The only way it seems to be to
handle our particular input (the nature/format of the input is covered
by an NDA so I can not discuss it in any detail) read the raw
request in the old servlet HttpServletRequest.getParameter() had a
nice side effect that we where able to do something like this:
public void doGet(HttpServletRequest request,HttpServletResponse response)
throws IOException
{
handleRequest(request,response);
}
public void doPost(HttpServletRequest request,HttpServletResponse response)
throws IOException
{
handleRequest(request,response);
}
private void handleRequest(HttpServletRequest
request,HttpServletResponse response)
{
String input=Request.getParameter(foo); // we are only interested
in this one param
process input
}
I want to preserve the single handler design but since getParameter
barfs on our new input format and there is no unified raw input reader
the only thing I can think of is make it so doGet and doPost use
request.getQueryString() and request.getReader() respectivally... is
there an easier way? (namely I want to keep doXXX as pure wrappers with
nothing but a dispatch to handleRequest()).
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: smaller, faster tomcat?
Edwin Ansicodd wrote: developing a web app on tomcat, restarting tomcat is taking up time. Is there a smaller tomcat or settings for development on tomcat that allow for faster development? If your not modifing the files in $CATALINA_BASE/conf then setting reloadable=true in your Context in the Host tag in server.xml will do it and/or you can use the manager to do this - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: public_html config not working
Caldarale, Charles R wrote: From: Aryeh Friedman [mailto:aryeh.fried...@gmail.com] Subject: public_html config not working I took following from cutting and pasting from O'Reilly's Defenative Tomcat and put it inside each of my virtual hosts (as shown the default Host) and then I get resource unavaible for any request to ~user but the rest of the (virtual) host works: Listener className=org.apache.catalina.startup.UserConfig directoryName=public_html userClass=org.apache.catalina.startup.PasswdUserDatabase /Listener http://www.catb.org/~esr/faqs/smart-questions.html At the bare minimum, tell us the Tomcat version you're using, the JVM it's running on, and the platform - we're not mind readers. If you tried the above on Windows, it will certainly fail. The real doc for that feature of the current Tomcat version is here: http://tomcat.apache.org/tomcat-6.0-doc/config/host.html#User%20Web%20Applications Tomcat 6.0.20, JDK 1.6 update 3 (with FreeBSD patch 4), FreeBSD 7.2-RELEASEpl1 (development machine) and 8.0-RELEASE (production machine) I also forgot to note I had it working fine on localhost but it seems to not like virtual hosts - 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Including a file into server.xml
I have an Java based XML DB that keeps track of different configurations for various sites we host and it is trivial to have it spit out a Host entery compatible with server.xml for each site... the only problem we have is how to insert the output into server.xml without garbaging and/or having to parse the file... the solution I want to use is include file X here but I can not find any way of coding that into server.xml If it is compatible with standard XML inclusion tag's just let me know and I will figure out the rest if not is there a special tag or something? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
