Re: MacOS X - Changing JAVA_OPTS for 8859_1 encoding
I think the correct syntax would be: JAVA_OPTS="-Dfile.encoding=8859_1" The quotes aren't really important, but the -D is. If that was just a typo in your message, then I'm not really sure what the problem is. But if that was actually what's in your script, it won't have the effect of setting a system property in Java unless the -D is there. (I really don't know anything about the file.encoding property in particular, or it's behavior, so I can't help you there.) On 3/17/02 4:03 AM, "Steven Elliott" <[EMAIL PROTECTED]> wrote: > Sorry if this is off topic but I know there are OSX, Tomcat users here who > may be able to shed some light on my problem. > > The problem has to do with ASCII characters >128 for locale character > support such as tilde, circumflex, etc. while running Tomcat (4.0.3) on > MacOS 10.1.3 w/ java version 1.3.1 > > I have set my JAVA_OPTS env variable to file.encoding=8859_1 but am still > having problems with ResultSet values which continue to be MacRoman > decoding of 8859_1 chars. > > I am accessing a MSSQL running on Windows 2000 via a JDirect Type 4 driver. > Some of the data has Portuguese and Spanish characters and when I output a > ResultSet returned by Tomcat running on the Windows machine everything looks > correct. When I output the same ResultSet from Tomcat running on the > Macintosh accessing the same database on the Windows machine, I get the > characters MacRoman encoded whether or not I have run the startup.sh from a > terminal with JAVA_OPTS=file.encoding=8859_1. Actually there is NO > difference which seems to indicate that either file.properties is not the > correct system env variable or I am not using JAVA_OPTS correctly? > > So I'm fishing for any ideas of how to fix this problem. If you have any > suggestions please mail me off list as well as I am on the digest. > > Thanks for the help. > > Steven > > //* > * VTV Learning Corporation > *Los Angeles - Boston - Lisbon > * (http://www.vtvLearning.com/) > */ > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- +---+ | Dave Makower<[EMAIL PROTECTED]> | | http://www.davemak.com/ | +---+ -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
Re: tomcat 4, default XML parser, XSLT, Xalan Configuration
We had exactly the same problem. Turns out it's a known bug (or perhaps "mis-feature") in Tomcat 4.0.3. We downloaded 4.0.4b1, and it worked again without us having to change anything in our code. On 3/17/02 9:54 AM, "Brendan Colthurst" <[EMAIL PROTECTED]> wrote: > > I had a simple XML / XSLT transform utility working with tomcat 3.2.3 > using the xalan and xerces libraries. > > I upgraded to tomcat 4.0.3, and now the utility throws configuration > exceptions. I'm having trouble getting the details of the exceptions > because they're all wrapped up in servlet exception wrappers... > > I've read some posts with complaints about the inability to use other XML > parsers. My problem is, I wouldn't mind using the standard xerces parser > that comes with tomcat 4.0 -- I just can't seem to get it to work... > > I'm assuming that I don't have to change anything in my tomcat installation > directory, but that I do have to provide some xslt libraries in my > webapps/webapp/WEB-INF/lib directory. > > Does anyone have an example configuration using xalan XSLT and Tomcat 4? > > Thanks for your help, > Brendan > > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- +---+ | Dave Makower<[EMAIL PROTECTED]> | | http://www.davemak.com/ | +---+ -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
REQUEST: Need latest mod_webapp.so binary for Win32
I do not have the necessary tools to compile mod_webapp.so for Win32, but I have done a diff on the sources for webapp.c which indicate that a change that was committed since the most recent downloadable binary (from the Tomcat 4.0.1 binary directory) may address an issue we've been having. Would it be possible for someone who IS able to build it to do so from the latest sources (perhaps based on the tomcat_404_b1 CVS label) to do so and email it to me and/or upload the binary to the public distribution? I would be very grateful. -- +---+ | Dave Makower<[EMAIL PROTECTED]> | | http://www.davemak.com/ | +---+ -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
Tomcat 4.0.3 ClassLoader Problem
My app used to work on Tomcat 4.0.1, but now I get a java.lang.NoClassDefFoundError whenever the application tries to use one of our custom tags: in particular, it's a tag that uses XSLT transformations. The class that is not found is javax.xml.transform.TransformerConfigurationException, which is located in the xml-apis.jar file, located in our webapp's WEB-INF/lib directory. This file came with Xalan. I've attached a stack trace below. Notice that the error happens in introspecting on the Tag bean. From this I infer that whatever class is introspecting on the bean was loaded by a ClassLoader that does not have visibility to classes loaded from the webapp's WEB-INF/lib directory. (Can someone confirm this?) Is this a bug or a feature? Can anyone confirm that my analysis above is correct, or else explain where I've failed to analyze the situation properly? Does anyone have any suggestions as to how I can fix this problem? Now, it's possible that I could work around this problem by moving xerces.jar out of catalina's common/lib directory, as described by the release notes (as a way of preventing Tomcat from providing an XML parser to all webapps). But this would require everyone installing the app to modify their tomcat installation, and I want our webapp to work with a vanilla tomcat installation, out of the box. --- Stack trace: java.lang.NoClassDefFoundError: javax/xml/transform/TransformerConfigurationException at java.lang.Class.getMethods0(Native Method) at java.lang.Class.getDeclaredMethods(Class.java:1039) at java.beans.Introspector$1.run(Introspector.java:852) at java.security.AccessController.doPrivileged(Native Method) at java.beans.Introspector.getPublicDeclaredMethods(Introspector.java:850) at java.beans.Introspector.getTargetEventInfo(Introspector.java:556) at java.beans.Introspector.getBeanInfo(Introspector.java:294) at java.beans.Introspector.getBeanInfo(Introspector.java:81) at org.apache.jasper.compiler.TagCache.setTagHandlerClass(TagCache.java:116) at org.apache.jasper.compiler.TagBeginGenerator.init(TagBeginGenerator.java:146 ) at org.apache.jasper.compiler.JspParseEventListener$GeneratorWrapper.init(JspPa rseEventListener.java:822) at org.apache.jasper.compiler.JspParseEventListener.addGenerator(JspParseEventL istener.java:151) at org.apache.jasper.compiler.JspParseEventListener.handleTagBegin(JspParseEven tListener.java:1032) at org.apache.jasper.compiler.DelegatingListener.handleTagBegin(DelegatingListe ner.java:217) at org.apache.jasper.compiler.DelegatingListener.handleTagBegin(DelegatingListe ner.java:212) at org.apache.jasper.compiler.Parser$Tag.accept(Parser.java:878) at org.apache.jasper.compiler.Parser.parse(Parser.java:1145) at org.apache.jasper.compiler.Parser.parse(Parser.java:1103) at org.apache.jasper.compiler.Parser.parse(Parser.java:1099) at org.apache.jasper.compiler.ParserController.parse(ParserController.java:213) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:210) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:552) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspSe rvlet.java:177) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja va:189) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) -- +-------+ | Dave Makower<[EMAIL PROTECTED]> | | http://www.davemak.com/ | +---+ -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
Re: IE 5 on Mac is incompatible with TC 4?
On 3/8/02 11:36 AM, "Anders Rundgren" <[EMAIL PROTECTED]> wrote: > 2. Actually, we do absolutely nothing but "request.getSession()" which > triggers the session-mechanism according to my fellow developer. I.e. > we don't handle cookies ourselves, we rely on Tomcat's handling which > has worked fine until we started to mess with Mac and IE 5. Perhaps there is something in the configuration of your server (server.xml), or its default webapp settings (conf/web.xml), or the configuration of your webapp (WEB-INF/web.xml) that is causing the session cookie to be set as a secure cookie. > Note, we don't switch between HTTP and HTTPS, but you are right in your > comment. If you're only responding to HTTPS, then you probably don't need to set the Secure flag on the cookie anyway. I would bet that if you can find a way to get tomcat not to set that flag, your problem may go away. -- +-------+ | Dave Makower<[EMAIL PROTECTED]> | | http://www.davemak.com/ | +---+ -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
Re: IE 5 on Mac is incompatible with TC 4?
I've been watching this thread with some interest, because I have had no difficulty using cookie-based sessions on Tomcat 4.0.1 with Mac OS X and IE. Judging from the headers you reproduced in your email, it would appear the Tomcat has been configured in such a way as to treat the session cookie as secure, which means that it should ONLY be sent over an encrypted connection. As a result, the browser will NOT send the cookie over a regular HTTP session, so if you switch back and forth between regular HTTP and HTTP/SSL (i.e., "https"), the requests will not use the same session. In order to maintain sessions across HTTP and HTTPS, we use a non-secure cookie as the session ID (I think this is the default, anyway). Once someone logs in, which we only allow to occur over SSL, we and set a secure cookie with a randomly-generated value in the response. After that, we redirect all traffic that requires a logged-in user to HTTPS, and only treat them as really logged in if the secure cookie is present, and matches the value generated by us when they logged in. This allows us to switch the browser back and forth between HTTP and HTTPS at will, and only require the user to log in once per session. The system described above relies on correct behavior of cookies on the Mac in IE, and it works for us. I don't know if any behavior on the Tomcat side has changed since 4.0.1, but I would tend to doubt it. Why are you using a secure cookie for the session cookie? Do you need to? If so, you can't expect the session to remain intact across HTTP and HTTPS requests. Any browser that DOES send a secure cookie over a straight HTTP request is dangerously out of spec. On 3/8/02 10:32 AM, "Anders Rundgren" <[EMAIL PROTECTED]> wrote: > Just done! No cookies are sent from IE which means that TC is likely > to send something IE 5 Mac does not understand. "Secure" is an addition that > TC offer but not IIS. Secure is though RFC-compliant so maybe IE 5/mac > *is* broken. > > TOMCAT > --- > Date: Fri, 08 Mar 2002 15:00:42 GMT > Server: Apache/1.3.23 (Unix) mod_ssl/2.8.6 OpenSSL/0.9.6 mod_jk/1.2.0 > EXPIRES: Thu, 01 Jan 1970 00:00:00 GMT > Set-Cookie: JSESSIONID=7C1F8E3DD950780CA775B3EB3AE74D16;Path=/BuyerASP;Secure > Connection: close > Content-Type: text/html > > IIS > --- > Server: Microsoft-IIS/5.0 > Date: Fri, 08 Mar 2002 15:13:12 GMT > Connection: Keep-Alive > Content-Length: 1443 > Content-Type: text/html > Expires: Fri, 08 Mar 2002 15:12:12 GMT > Set-Cookie: ASPSESSIONIDGQQGGWNY=INDLBBEAKPOBKEMFDDDHAFCM; path=/shop > Cache-control: private -- +---+ | Dave Makower<[EMAIL PROTECTED]> | | http://www.davemak.com/ | +---+ -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
mod_webapp + mos_ssl: Win32 discrepancy (should I use mod_jkinstead?)
I've managed to get mod_webapp and mod_ssl working together on both Solaris 2.6 and Mac OS X, without much trouble. However, I'm finding a discrepancy when I deploy the same app on Windows. On Solaris and Mac OS X, HTTPS requests arriving at the Apache server that are forwarded to Tomcat via the Warp protocol maintain the "https" scheme. So if you say getScheme() to the HttpServletRequest, it returns "https". But on Win32, getScheme() returns "http", even for those requests that come to Apache over SSL. I have tried creating two Warp connectors, and setting the "scheme" and "secure" attributes on the Connector element in server.xml, but that didn't change anything. The end result is that my application, which programmatically redirects the browser to https if it detects an http connection for certain functionality, gets caught in an endless redirect loop. Any suggestions as to how to fix or work around this problem? I'd try to recompile mod_webapp myself, but I'm not sure what tools I need to compile it for the Windows platform. I'm using Tomcat and mod_webapp versions 4.0.1, with Apache 1.3.23, mod_ssl 2.8.6, and OpenSSL 0.9.6c. A related question (probably a FAQ, but I didn't find it addressed anywhere): what is the relationship between mod_webapp and mod_jk, and is there any reason to use mod_jk instead of mod_webapp, or vice versa? -- +---+ | Dave Makower<[EMAIL PROTECTED]> | | http://www.davemak.com/ | +---+ -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>