Re: tomcat 4, default XML parser, XSLT, Xalan Configuration

2002-03-18 Thread Dave Makower

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]




Re: MacOS X - Changing JAVA_OPTS for 8859_1 encoding

2002-03-18 Thread Dave Makower

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]




REQUEST: Need latest mod_webapp.so binary for Win32

2002-03-13 Thread Dave Makower

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]




Re: IE 5 on Mac is incompatible with TC 4?

2002-03-08 Thread Dave Makower

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]




Re: IE 5 on Mac is incompatible with TC 4?

2002-03-08 Thread Dave Makower

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]




Tomcat 4.0.3 ClassLoader Problem

2002-03-08 Thread Dave Makower

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]




mod_webapp + mos_ssl: Win32 discrepancy (should I use mod_jkinstead?)

2002-03-05 Thread Dave Makower

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]