RE: Arabic encoding

2005-05-17 Thread Fadwa Barham
I agree with you that I have to change my oracle encoding, and everything will 
work fine,
but it is not easy to change the configuration of oracle in my company, cause 
we are upgrading an old system, and cause we are in an intermediat stage, I 
need to use oracle with us7ascii now, in the future we will change the 
configuration of oracle. and until we change the oracle configuration, I need 
to make advantage of the new versions of Java and tomcat.
 
thanks

Benson Margulies [EMAIL PROTECTED] wrote:
Why do you expect this to work with the us7 oracle encoding? The JDBC
driver will work very hard to force all your Arabic characters to turn
into ? marks with this configuration. You must use UTF-8 or CP1256 or
ISO-8869-6 in Oracle.

-Original Message-
From: Fadwa Barham [mailto:[EMAIL PROTECTED] 
Sent: Saturday, May 14, 2005 12:56 AM
To: Tomcat Users List
Subject: Re: Arabic encoding

thanks for your reply.

I agree with you that utf-8 encoding is suitable for all cases, but in
tc4 with jdk1.3, I write the servlets and compile them and use data from
oracle with us7ascii encoding, and I don't set any encoding except:
pw.println(content=\ar-sa\);
pw.println(content=\text/html;charset=windows-1256\);
and the page display all the characters correctly.
I think sun microsystems and tomcat made changes to the new packages
about encoding.
but how to deal with the new changed? Is there special setup I've to do?

thanks 
Fadwa


Mark Thomas wrote:
There are lots of potential pitfalls when using non-default character 
encodings. It is easy to make mistakes both with Tomcat settings and 
with your code.

To sort out the tomcat settings, get the following index.jsp to work for

whatever text you supply to the form. I have tested this with the latest

TC4 and TC5 code and it works for me with any text I choose to enter.

Once you have this working, you can look at your application and see 
what is different.

Mark









Data posted to this form was:
request.setCharacterEncoding(UTF-8);
out.print(request.getParameter(mydata));
%



enctype=application/x-www-form-urlencoded
[input] 
[input] 
[input] 




Fadwa Barham wrote:
 While I was searching for a solution for the encoding, I found this
 
 There is a standard for encoding URIs
(http://www.w3.org/International/O-URL-
 code.html) but this standard is not consistently followed by clients.
This 
 causes a number of problems.
 
 The functionality provided by Tomcat (4 and 5) to handle this less
than ideal 
 situation is described below.
 
 1. The Coyote HTTP/1.1 connector has a useBodyEncodingForURI attribute
which 
 if set to true will use the request body encoding to decode the URI
query 
 parameters.
 - The default value is true for TC4 (breaks spec but gives consistent 
 behaviour across TC4 versions)
 - The default value is false for TC5 (spec compliant but there may be 
 migration issues for some apps)
 2. The Coyote HTTP/1.1 connector has a URIEncoding attribute which
defaults to 
 ISO-8859-1.
 3. The parameters class (o.a.t.u.http.Parameters) has a
QueryStringEncoding 
 field which defaults to the URIEncoding. It must be set before the
parameters 
 are parsed to have an effect.
 
 Things to note regarding the servlet API:
 1. HttpServletRequest.setCharacterEncoding() normally only applies to
the 
 request body NOT the URI.
 2. HttpServletRequest.getPathInfo() is decoded by the web container.
 3. HttpServletRequest.getRequestURI() is not decoded by container.
 
 Other tips:
 1. Use POST with forms to return parameters as the parameters are then
part of 
 the request body.
 
 
 Is this means that the changes between tc4 and tc5 about encoding is
the reason why I can't have the write encoding in the new versions of
tomcat? and if so, how to solve the problem?
 
 Thanks
 
 - Original Message - 
 From: Fadwa Barham 
 To: Tomcat Users List 
 Sent: Tuesday, March 01, 2005 3:24 AM
 Subject: Re: Arabic encoding
 
 
 
As tomcat 4.1.31 is suitable for arabic and it seems until now that
tomcat 
4.1.31 solved the jndi datasource problems: Intermittent dB connection

Failures and Random Connection closed Exceptions
I will use tomcat 4.1.31 until I can configure the latest versions of 
tomcat.
I feel not lucky
- Original Message - 
From: Fadwa Barham 
To: Tomcat Users List 
Sent: Tuesday, March 01, 2005 2:39 AM
Subject: Re: Arabic encoding



I tested many tomcat versions, I found until tomcat 4.1.31 no
problems 
with arabic, but when I tried tomcat-4.1.18 and newer versions, I
faced 
the same problem.

- Original Message - 
From: Benson Margulies 
To: Tomcat Users List 
Sent: Sunday, February 27, 2005 4:08 PM
Subject: RE: Arabic encoding



It depends on what the Oracle JDBC driver does with byte values that
are
not legitimate US7ASCII. If, for some reason, it treated the data as
ISO-8859-1 instead of US7ASCII, then it might have streamed out
through
tomcat, and the browser would have auto-detected the CP1256
pretending
to be ISO-8859-1

Re: Arabic encoding

2005-05-14 Thread Fadwa Barham
I tried what you suggested, the characters that I write inside the servlet will 
be displayed correctly, but the data from database are question marks.
it is true that remote debugging is not easy, but many programmers face this 
problem who use languages other than english,french,espanol. I found subjects 
about encoding in the bug database. but I could't have clear answer.
 
 


Mark Thomas [EMAIL PROTECTED] wrote:
From re-reading this thread it sounds as if an invalid assumption is 
being made somewhere about the encoding of your database data.

I would suggest the following:
1. Use res.setContentType(text/html; charset=UTF-8) or
res.setContentType(text/html; charset=windows-1256) in your servlets.

2. Write a simple (one character) test case for reading your database 
data and debug what is going on. At some point there will be something 
like a getReader(), getWriter() or similar that doesn't specify an 
encoding and this will be the problem.

Personally I find remote debugging invaluable in cases such as this so I 
can be sure I am seeing the real data.

Mark

Fadwa Barham wrote:
 thanks for your reply.
 
 I agree with you that utf-8 encoding is suitable for all cases, but in tc4 
 with jdk1.3, I write the servlets and compile them and use data from oracle 
 with us7ascii encoding, and I don't set any encoding except:
 pw.println();
 pw.println();
 and the page display all the characters correctly.
 I think sun microsystems and tomcat made changes to the new packages about 
 encoding.
 but how to deal with the new changed? Is there special setup I've to do?
 
 thanks 
 Fadwa
 
 
 Mark Thomas wrote:
 There are lots of potential pitfalls when using non-default character 
 encodings. It is easy to make mistakes both with Tomcat settings and 
 with your code.
 
 To sort out the tomcat settings, get the following index.jsp to work for 
 whatever text you supply to the form. I have tested this with the latest 
 TC4 and TC5 code and it works for me with any text I choose to enter.
 
 Once you have this working, you can look at your application and see 
 what is different.
 
 Mark
 
 
 
 
 
 
 
 
 
 Data posted to this form was:
 request.setCharacterEncoding(UTF-8);
 out.print(request.getParameter(mydata));
 %
 
 
 
 enctype=application/x-www-form-urlencoded
 [input] 
 [input] 
 [input] 
 
 
 
 
 Fadwa Barham wrote:
 
While I was searching for a solution for the encoding, I found this

There is a standard for encoding URIs (http://www.w3.org/International/O-URL-
code.html) but this standard is not consistently followed by clients. This 
causes a number of problems.

The functionality provided by Tomcat (4 and 5) to handle this less than ideal 
situation is described below.

1. The Coyote HTTP/1.1 connector has a useBodyEncodingForURI attribute which 
if set to true will use the request body encoding to decode the URI query 
parameters.
- The default value is true for TC4 (breaks spec but gives consistent 
behaviour across TC4 versions)
- The default value is false for TC5 (spec compliant but there may be 
migration issues for some apps)
2. The Coyote HTTP/1.1 connector has a URIEncoding attribute which defaults 
to 
ISO-8859-1.
3. The parameters class (o.a.t.u.http.Parameters) has a QueryStringEncoding 
field which defaults to the URIEncoding. It must be set before the parameters 
are parsed to have an effect.

Things to note regarding the servlet API:
1. HttpServletRequest.setCharacterEncoding() normally only applies to the 
request body NOT the URI.
2. HttpServletRequest.getPathInfo() is decoded by the web container.
3. HttpServletRequest.getRequestURI() is not decoded by container.

Other tips:
1. Use POST with forms to return parameters as the parameters are then part 
of 
the request body.


Is this means that the changes between tc4 and tc5 about encoding is the 
reason why I can't have the write encoding in the new versions of tomcat? and 
if so, how to solve the problem?

Thanks

- Original Message - 
From: Fadwa Barham 
To: Tomcat Users List 
Sent: Tuesday, March 01, 2005 3:24 AM
Subject: Re: Arabic encoding




As tomcat 4.1.31 is suitable for arabic and it seems until now that tomcat 
4.1.31 solved the jndi datasource problems: Intermittent dB connection 
Failures and Random Connection closed Exceptions
I will use tomcat 4.1.31 until I can configure the latest versions of 
tomcat.
I feel not lucky
- Original Message - 
From: Fadwa Barham 
To: Tomcat Users List 
Sent: Tuesday, March 01, 2005 2:39 AM
Subject: Re: Arabic encoding




I tested many tomcat versions, I found until tomcat 4.1.31 no problems 
with arabic, but when I tried tomcat-4.1.18 and newer versions, I faced 
the same problem.

- Original Message - 
From: Benson Margulies 
To: Tomcat Users List 
Sent: Sunday, February 27, 2005 4:08 PM
Subject: RE: Arabic encoding




It depends on what the Oracle JDBC driver does with byte values that are
not legitimate US7ASCII. If, for some reason, it treated the data

Re: Arabic encoding

2005-05-13 Thread Fadwa Barham
thanks for your reply.
 
I agree with you that utf-8 encoding is suitable for all cases, but in tc4 with 
jdk1.3, I write the servlets and compile them and use data from oracle with 
us7ascii encoding, and I don't set any encoding except:
  pw.println(meta http-equiv=\Content-Language\ content=\ar-sa\);
  pw.println(META http-equiv=Content-Type 
content=\text/html;charset=windows-1256\);
and the page display all the characters correctly.
I think sun microsystems and tomcat made changes to the new packages about 
encoding.
but how to deal with the new changed? Is there special setup I've to do?
 
thanks 
Fadwa


Mark Thomas [EMAIL PROTECTED] wrote:
There are lots of potential pitfalls when using non-default character 
encodings. It is easy to make mistakes both with Tomcat settings and 
with your code.

To sort out the tomcat settings, get the following index.jsp to work for 
whatever text you supply to the form. I have tested this with the latest 
TC4 and TC5 code and it works for me with any text I choose to enter.

Once you have this working, you can look at your application and see 
what is different.

Mark









Data posted to this form was:
   request.setCharacterEncoding(UTF-8);
   out.print(request.getParameter(mydata));
 %



enctype=application/x-www-form-urlencoded
 [input] 
 [input] 
 [input] 




Fadwa Barham wrote:
 While I was searching for a solution for the encoding, I found this
 
 There is a standard for encoding URIs (http://www.w3.org/International/O-URL-
 code.html) but this standard is not consistently followed by clients. This 
 causes a number of problems.
 
 The functionality provided by Tomcat (4 and 5) to handle this less than ideal 
 situation is described below.
 
 1. The Coyote HTTP/1.1 connector has a useBodyEncodingForURI attribute which 
 if set to true will use the request body encoding to decode the URI query 
 parameters.
 - The default value is true for TC4 (breaks spec but gives consistent 
 behaviour across TC4 versions)
 - The default value is false for TC5 (spec compliant but there may be 
 migration issues for some apps)
 2. The Coyote HTTP/1.1 connector has a URIEncoding attribute which defaults 
 to 
 ISO-8859-1.
 3. The parameters class (o.a.t.u.http.Parameters) has a QueryStringEncoding 
 field which defaults to the URIEncoding. It must be set before the parameters 
 are parsed to have an effect.
 
 Things to note regarding the servlet API:
 1. HttpServletRequest.setCharacterEncoding() normally only applies to the 
 request body NOT the URI.
 2. HttpServletRequest.getPathInfo() is decoded by the web container.
 3. HttpServletRequest.getRequestURI() is not decoded by container.
 
 Other tips:
 1. Use POST with forms to return parameters as the parameters are then part 
 of 
 the request body.
 
 
 Is this means that the changes between tc4 and tc5 about encoding is the 
 reason why I can't have the write encoding in the new versions of tomcat? and 
 if so, how to solve the problem?
 
 Thanks
 
 - Original Message - 
 From: Fadwa Barham 
 To: Tomcat Users List 
 Sent: Tuesday, March 01, 2005 3:24 AM
 Subject: Re: Arabic encoding
 
 
 
As tomcat 4.1.31 is suitable for arabic and it seems until now that tomcat 
4.1.31 solved the jndi datasource problems: Intermittent dB connection 
Failures and Random Connection closed Exceptions
I will use tomcat 4.1.31 until I can configure the latest versions of 
tomcat.
I feel not lucky
- Original Message - 
From: Fadwa Barham 
To: Tomcat Users List 
Sent: Tuesday, March 01, 2005 2:39 AM
Subject: Re: Arabic encoding



I tested many tomcat versions, I found until tomcat 4.1.31 no problems 
with arabic, but when I tried tomcat-4.1.18 and newer versions, I faced 
the same problem.

- Original Message - 
From: Benson Margulies 
To: Tomcat Users List 
Sent: Sunday, February 27, 2005 4:08 PM
Subject: RE: Arabic encoding



It depends on what the Oracle JDBC driver does with byte values that are
not legitimate US7ASCII. If, for some reason, it treated the data as
ISO-8859-1 instead of US7ASCII, then it might have streamed out through
tomcat, and the browser would have auto-detected the CP1256 pretending
to be ISO-8859-1.

-Original Message-
From: Fadwa Barham [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 27, 2005 1:43 PM
To: Tomcat Users List
Subject: Re: Arabic encoding

But I wonder why the old tomcat and java displayed arabic correctly, and
I use the same classes12.jar in both of the old and the new.
I want to know what is the differance, what encoding they stopped to
support? It looks like that tomcat cannot understand the old Java cause
I have to change the encoding to arabic windows in the internet explorer
each time I request the servlet, and when I do this, every arabic
character is displayed correctly.
I think it is better to understand the problem and the changes so I can
handle the problem if I faced it again in the newer versions of tomcat
or Java.
I know that being

Re: Arabic encoding

2005-05-11 Thread Fadwa Barham
While I was searching for a solution for the encoding, I found this
 
There is a standard for encoding URIs (http://www.w3.org/International/O-URL-
code.html) but this standard is not consistently followed by clients. This 
causes a number of problems.

The functionality provided by Tomcat (4 and 5) to handle this less than ideal 
situation is described below.

1. The Coyote HTTP/1.1 connector has a useBodyEncodingForURI attribute which 
if set to true will use the request body encoding to decode the URI query 
parameters.
  - The default value is true for TC4 (breaks spec but gives consistent 
behaviour across TC4 versions)
  - The default value is false for TC5 (spec compliant but there may be 
migration issues for some apps)
2. The Coyote HTTP/1.1 connector has a URIEncoding attribute which defaults to 
ISO-8859-1.
3. The parameters class (o.a.t.u.http.Parameters) has a QueryStringEncoding 
field which defaults to the URIEncoding. It must be set before the parameters 
are parsed to have an effect.

Things to note regarding the servlet API:
1. HttpServletRequest.setCharacterEncoding() normally only applies to the 
request body NOT the URI.
2. HttpServletRequest.getPathInfo() is decoded by the web container.
3. HttpServletRequest.getRequestURI() is not decoded by container.

Other tips:
1. Use POST with forms to return parameters as the parameters are then part of 
the request body.


Is this means that the changes between tc4 and tc5 about encoding is the reason 
why I can't have the write encoding in the new versions of tomcat? and if so, 
how to solve the problem?
 
Thanks

- Original Message - 
From: Fadwa Barham 
To: Tomcat Users List 
Sent: Tuesday, March 01, 2005 3:24 AM
Subject: Re: Arabic encoding


 As tomcat 4.1.31 is suitable for arabic and it seems until now that tomcat 
 4.1.31 solved the jndi datasource problems: Intermittent dB connection 
 Failures and Random Connection closed Exceptions
 I will use tomcat 4.1.31 until I can configure the latest versions of 
 tomcat.
 I feel not lucky
 - Original Message - 
 From: Fadwa Barham 
 To: Tomcat Users List 
 Sent: Tuesday, March 01, 2005 2:39 AM
 Subject: Re: Arabic encoding


I tested many tomcat versions, I found until tomcat 4.1.31 no problems 
with arabic, but when I tried tomcat-4.1.18 and newer versions, I faced 
the same problem.

 - Original Message - 
 From: Benson Margulies 
 To: Tomcat Users List 
 Sent: Sunday, February 27, 2005 4:08 PM
 Subject: RE: Arabic encoding


 It depends on what the Oracle JDBC driver does with byte values that are
 not legitimate US7ASCII. If, for some reason, it treated the data as
 ISO-8859-1 instead of US7ASCII, then it might have streamed out through
 tomcat, and the browser would have auto-detected the CP1256 pretending
 to be ISO-8859-1.

 -Original Message-
 From: Fadwa Barham [mailto:[EMAIL PROTECTED]
 Sent: Sunday, February 27, 2005 1:43 PM
 To: Tomcat Users List
 Subject: Re: Arabic encoding

 But I wonder why the old tomcat and java displayed arabic correctly, and
 I use the same classes12.jar in both of the old and the new.
 I want to know what is the differance, what encoding they stopped to
 support? It looks like that tomcat cannot understand the old Java cause
 I have to change the encoding to arabic windows in the internet explorer
 each time I request the servlet, and when I do this, every arabic
 character is displayed correctly.
 I think it is better to understand the problem and the changes so I can
 handle the problem if I faced it again in the newer versions of tomcat
 or Java.
 I know that being the database in us7ascii is not good, but changing the
 database encoding each time I face the problem is not the right way. I
 may change it this time, but I need to understand.
 thanks

 - Original Message -
 From: Benson Margulies 
 To: Tomcat Users List 
 Sent: Sunday, February 27, 2005 12:44 AM
 Subject: RE: Arabic encoding


 Oracle's ODBC driver will transcode from the database to UTF-16 based
 on
 the databse encoding. If the database is in US7ASCII, this is a
 destructive process for Arabic. The only alternative I can think of is
 to do all your database I/O in hex.

 -Original Message-
 From: Fadwa Barham [mailto:[EMAIL PROTECTED]
 Sent: Saturday, February 26, 2005 1:20 PM
 To: Tomcat Users List
 Subject: Re: Arabic encoding

 I use oracle 7 database, and the NLS language is
 American_America.US7ASCII, and it is not easy to change it to utf-8.
 Beside, the question is, a servlet work fine on tomcat 4.0.6 why it
 stopped with the new versions, what changes made to the encoding of
 tomcat??
 do I need tomcat-i18n-ar.jar? and if so, from where to get it?
 I can't determine where is the problem, is it from the new Java or the
 new tomcat.
 thanks in advanced

 - Original Message -
 From: Benson Margulies 
 To: Tomcat Users List 
 Sent: Wednesday, February 23, 2005 11:26 PM
 Subject: RE: Arabic encoding


 What database? Do you

Re: All threads (250) are currently busy

2005-04-20 Thread Fadwa Barham
Hi,
I have the same problem, I read the reply, and I want to ask, how to use 
SIGQUIT?

regards
- Original Message - 
From: farhad [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, April 20, 2005 9:50 AM
Subject: Re: All threads (250) are currently busy


I don't know what kind of application you are running, but most likely
you have a resource leak; Do a thread dump and see what your threads
are waiting for. Most likely they are just in wait state and no CPU
usage. It could be cause by lots of things. One problem could be
using jdbc and not closing your connection or returning it to your pool.
For testing reduce your resource limit, don't increase it (reduce Max
thread, and connection pool). This would cause system hangs faster.
Send a SIGQUIT signal to VM and look at state of your threads and its
location (don't post your thread dump!)
Paul Grimwood wrote:
Tomcat hangs intermittently (1 to 10 days) with the following message in 
catalina.out

20/04/2005 13:48:09 org.apache.tomcat.util.threads.ThreadPool logFull
SEVERE: All threads (250) are currently busy, waiting. Increase maxThreads 
(250) or check the servlet status

We are running tomcat 5.5.7 on jdk1.5.0_02 under Redhat Linux Fedora Core 
2 against an Oracle9 DB.

I have seen various posts to this with suggestions including setting Linux 
threads with LD_ASSUME_KERNEL (tried but problem still exists) and setting 
connection timeout in server.xml from 0 to 6 (but ours is set at 2 
already). And we have already upgraded to latest Tomcat and JRE to no 
avail. Despite reviewing the mailing list over the past 18 to 24 months, i 
am none the wiser.
The problem started around the time we deployed the code onto a new server 
running a later Linux version but this could be a red herring and I 
suspect it is a database connection issue. Has anyone got any ideas?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED] 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: All threads (250) are currently busy

2005-04-20 Thread Fadwa Barham
I forgot to say that I'm using windows  not linux
- Original Message - 
From: Fadwa Barham [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, April 20, 2005 11:36 AM
Subject: Re: All threads (250) are currently busy


Hi,
I have the same problem, I read the reply, and I want to ask, how to use 
SIGQUIT?

regards
- Original Message - 
From: farhad [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, April 20, 2005 9:50 AM
Subject: Re: All threads (250) are currently busy


I don't know what kind of application you are running, but most likely
you have a resource leak; Do a thread dump and see what your threads
are waiting for. Most likely they are just in wait state and no CPU
usage. It could be cause by lots of things. One problem could be
using jdbc and not closing your connection or returning it to your pool.
For testing reduce your resource limit, don't increase it (reduce Max
thread, and connection pool). This would cause system hangs faster.
Send a SIGQUIT signal to VM and look at state of your threads and its
location (don't post your thread dump!)
Paul Grimwood wrote:
Tomcat hangs intermittently (1 to 10 days) with the following message in 
catalina.out

20/04/2005 13:48:09 org.apache.tomcat.util.threads.ThreadPool logFull
SEVERE: All threads (250) are currently busy, waiting. Increase 
maxThreads (250) or check the servlet status

We are running tomcat 5.5.7 on jdk1.5.0_02 under Redhat Linux Fedora Core 
2 against an Oracle9 DB.

I have seen various posts to this with suggestions including setting 
Linux threads with LD_ASSUME_KERNEL (tried but problem still exists) and 
setting connection timeout in server.xml from 0 to 6 (but ours is set 
at 2 already). And we have already upgraded to latest Tomcat and JRE 
to no avail. Despite reviewing the mailing list over the past 18 to 24 
months, i am none the wiser.
The problem started around the time we deployed the code onto a new 
server running a later Linux version but this could be a red herring and 
I suspect it is a database connection issue. Has anyone got any ideas?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED] 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: All threads (250) are currently busy

2005-04-20 Thread Fadwa Barham
what's the correct configuration of the connector?
Regards
- Original Message - 
From: Zsolt Koppany [EMAIL PROTECTED]
To: 'Tomcat Users List' tomcat-user@jakarta.apache.org
Sent: Wednesday, April 20, 2005 11:08 AM
Subject: AW: All threads (250) are currently busy


We had the same problem, but after configuring the apache connector
correctly the problem disappeared.
Zsolt
-Ursprüngliche Nachricht-
Von: Paul Grimwood [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 20. April 2005 06:07
An: tomcat-user@jakarta.apache.org
Betreff: All threads (250) are currently busy
Tomcat hangs intermittently (1 to 10 days) with the following message in
catalina.out
20/04/2005 13:48:09 org.apache.tomcat.util.threads.ThreadPool logFull
SEVERE: All threads (250) are currently busy, waiting. Increase 
maxThreads
(250) or check the servlet status

We are running tomcat 5.5.7 on jdk1.5.0_02 under Redhat Linux Fedora Core
2 against an Oracle9 DB.
I have seen various posts to this with suggestions including setting 
Linux
threads with LD_ASSUME_KERNEL (tried but problem still exists) and 
setting
connection timeout in server.xml from 0 to 6 (but ours is set at 
2
already). And we have already upgraded to latest Tomcat and JRE to no
avail. Despite reviewing the mailing list over the past 18 to 24 months, 
i
am none the wiser.

The problem started around the time we deployed the code onto a new 
server
running a later Linux version but this could be a red herring and I
suspect it is a database connection issue. Has anyone got any ideas?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Arabic encoding

2005-02-28 Thread Fadwa Barham
I tested many tomcat versions, I found until tomcat 4.1.31 no problems with 
arabic, but when I tried tomcat-4.1.18 and newer versions, I faced the same 
problem.

- Original Message - 
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Sunday, February 27, 2005 4:08 PM
Subject: RE: Arabic encoding


It depends on what the Oracle JDBC driver does with byte values that are
not legitimate US7ASCII. If, for some reason, it treated the data as
ISO-8859-1 instead of US7ASCII, then it might have streamed out through
tomcat, and the browser would have auto-detected the CP1256 pretending
to be ISO-8859-1.
-Original Message-
From: Fadwa Barham [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 27, 2005 1:43 PM
To: Tomcat Users List
Subject: Re: Arabic encoding
But I wonder why the old tomcat and java displayed arabic correctly, and
I use the same classes12.jar in both of the old and the new.
I want to know what is the differance, what encoding they stopped to
support? It looks like that tomcat cannot understand the old Java cause
I have to change the encoding to arabic windows in the internet explorer
each time I request the servlet, and when I do this, every arabic
character is displayed correctly.
I think it is better to understand the problem and the changes so I can
handle the problem if I faced it again in the newer versions of tomcat
or Java.
I know that being the database in us7ascii is not good, but changing the
database encoding each time I face the problem is not the right way. I
may change it this time, but I need to understand.
thanks
- Original Message -
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Sunday, February 27, 2005 12:44 AM
Subject: RE: Arabic encoding

Oracle's ODBC driver will transcode from the database to UTF-16 based
on
the databse encoding. If the database is in US7ASCII, this is a
destructive process for Arabic. The only alternative I can think of is
to do all your database I/O in hex.
-Original Message-
From: Fadwa Barham [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 26, 2005 1:20 PM
To: Tomcat Users List
Subject: Re: Arabic encoding
I use oracle 7 database, and the NLS language is
American_America.US7ASCII, and it is not easy to change it to utf-8.
Beside, the question is, a servlet work fine on tomcat 4.0.6 why it
stopped with the new versions, what changes made to the encoding of
tomcat??
do I need tomcat-i18n-ar.jar? and if so, from where to get it?
I can't determine where is the problem, is it from the new Java or the
new tomcat.
thanks in advanced
- Original Message -
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, February 23, 2005 11:26 PM
Subject: RE: Arabic encoding

What database? Do you have the database set up to deliver Unicode, or
CP1256, correctly? Note that not all Arabic fits into CP1256, you
might
really be better off with UTF-8.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Arabic encoding

2005-02-28 Thread Fadwa Barham
As tomcat 4.1.31 is suitable for arabic and it seems until now that tomcat 
4.1.31 solved the jndi datasource problems: Intermittent dB connection 
Failures and  Random Connection closed Exceptions
I will use tomcat 4.1.31 until I can configure the latest versions of 
tomcat.
I feel not lucky
- Original Message - 
From: Fadwa Barham [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Tuesday, March 01, 2005 2:39 AM
Subject: Re: Arabic encoding


I tested many tomcat versions, I found until tomcat 4.1.31 no problems with 
arabic, but when I tried tomcat-4.1.18 and newer versions, I faced the same 
problem.

- Original Message - 
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Sunday, February 27, 2005 4:08 PM
Subject: RE: Arabic encoding


It depends on what the Oracle JDBC driver does with byte values that are
not legitimate US7ASCII. If, for some reason, it treated the data as
ISO-8859-1 instead of US7ASCII, then it might have streamed out through
tomcat, and the browser would have auto-detected the CP1256 pretending
to be ISO-8859-1.
-Original Message-
From: Fadwa Barham [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 27, 2005 1:43 PM
To: Tomcat Users List
Subject: Re: Arabic encoding
But I wonder why the old tomcat and java displayed arabic correctly, and
I use the same classes12.jar in both of the old and the new.
I want to know what is the differance, what encoding they stopped to
support? It looks like that tomcat cannot understand the old Java cause
I have to change the encoding to arabic windows in the internet explorer
each time I request the servlet, and when I do this, every arabic
character is displayed correctly.
I think it is better to understand the problem and the changes so I can
handle the problem if I faced it again in the newer versions of tomcat
or Java.
I know that being the database in us7ascii is not good, but changing the
database encoding each time I face the problem is not the right way. I
may change it this time, but I need to understand.
thanks
- Original Message -
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Sunday, February 27, 2005 12:44 AM
Subject: RE: Arabic encoding

Oracle's ODBC driver will transcode from the database to UTF-16 based
on
the databse encoding. If the database is in US7ASCII, this is a
destructive process for Arabic. The only alternative I can think of is
to do all your database I/O in hex.
-Original Message-
From: Fadwa Barham [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 26, 2005 1:20 PM
To: Tomcat Users List
Subject: Re: Arabic encoding
I use oracle 7 database, and the NLS language is
American_America.US7ASCII, and it is not easy to change it to utf-8.
Beside, the question is, a servlet work fine on tomcat 4.0.6 why it
stopped with the new versions, what changes made to the encoding of
tomcat??
do I need tomcat-i18n-ar.jar? and if so, from where to get it?
I can't determine where is the problem, is it from the new Java or the
new tomcat.
thanks in advanced
- Original Message -
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, February 23, 2005 11:26 PM
Subject: RE: Arabic encoding

What database? Do you have the database set up to deliver Unicode, or
CP1256, correctly? Note that not all Arabic fits into CP1256, you
might
really be better off with UTF-8.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED] 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Arabic encoding

2005-02-26 Thread Fadwa Barham
Hi,
I want to ask if the servlet_api has effect on encoding?
may be the changes are made in the new version in servlet_api encoding. 
Please, can anyone help me
thanks in advanced

- Original Message - 
From: Fadwa Barham [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Saturday, February 26, 2005 8:20 PM
Subject: Re: Arabic encoding


I use oracle 7 database, and the NLS language is
American_America.US7ASCII, and it is not easy to change it to utf-8.
Beside, the question is, a servlet work fine on tomcat 4.0.6 why it 
stopped with the new versions, what changes made to the encoding of 
tomcat??
do I need tomcat-i18n-ar.jar? and if so, from where to get it?
I can't determine where is the problem, is it from the new Java or the new 
tomcat.
thanks in advanced

- Original Message - 
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, February 23, 2005 11:26 PM
Subject: RE: Arabic encoding


What database? Do you have the database set up to deliver Unicode, or
CP1256, correctly? Note that not all Arabic fits into CP1256, you might
really be better off with UTF-8.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED] 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Arabic encoding

2005-02-26 Thread Fadwa Barham
But I wonder why the old tomcat and java displayed arabic correctly, and I 
use the same classes12.jar in both of the old and the new.
I want to know what is the differance, what encoding they stopped to 
support? It looks like that tomcat cannot understand the old Java cause I 
have to change the encoding to arabic windows in the internet explorer each 
time I request the servlet, and when I do this, every arabic character is 
displayed correctly.
I think it is better to understand the problem and the changes so I can 
handle the problem if I faced it again in the newer versions of tomcat or 
Java.
I know that being the database in us7ascii is not good, but changing the 
database encoding each time I face the problem is not the right way. I may 
change it this time, but I need to understand.
thanks

- Original Message - 
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Sunday, February 27, 2005 12:44 AM
Subject: RE: Arabic encoding


Oracle's ODBC driver will transcode from the database to UTF-16 based on
the databse encoding. If the database is in US7ASCII, this is a
destructive process for Arabic. The only alternative I can think of is
to do all your database I/O in hex.
-Original Message-
From: Fadwa Barham [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 26, 2005 1:20 PM
To: Tomcat Users List
Subject: Re: Arabic encoding
I use oracle 7 database, and the NLS language is
American_America.US7ASCII, and it is not easy to change it to utf-8.
Beside, the question is, a servlet work fine on tomcat 4.0.6 why it
stopped with the new versions, what changes made to the encoding of
tomcat??
do I need tomcat-i18n-ar.jar? and if so, from where to get it?
I can't determine where is the problem, is it from the new Java or the
new tomcat.
thanks in advanced
- Original Message -
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, February 23, 2005 11:26 PM
Subject: RE: Arabic encoding

What database? Do you have the database set up to deliver Unicode, or
CP1256, correctly? Note that not all Arabic fits into CP1256, you
might
really be better off with UTF-8.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Arabic encoding

2005-02-25 Thread Fadwa Barham
I use oracle 7 database, and the NLS language is
American_America.US7ASCII, and it is not easy to change it to utf-8.
Beside, the question is, a servlet work fine on tomcat 4.0.6 why it stopped 
with the new versions, what changes made to the encoding of tomcat??
do I need tomcat-i18n-ar.jar? and if so, from where to get it?
I can't determine where is the problem, is it from the new Java or the new 
tomcat.
thanks in advanced

- Original Message - 
From: Benson Margulies [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, February 23, 2005 11:26 PM
Subject: RE: Arabic encoding


What database? Do you have the database set up to deliver Unicode, or
CP1256, correctly? Note that not all Arabic fits into CP1256, you might
really be better off with UTF-8.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Arabic encoding

2005-02-23 Thread Fadwa Barham
Hi,
 I face difficulties with encoding, at first I developed servlets that connects 
to oracle database, the oracle encoding is US7Ascii and it contains arabic 
data, I used Java1.3 to write the code and tomcat 4.0.6 to deploy the servlets, 
I just needed to get the write encoding of the servlets, both the data from the 
database or the messages I write in the code in arabic, is puting these lines 
in the servlet
meta http-equiv=Content-Language content=ar-sa
META http-equiv=Content-Type content=text/html;charset=windows-1256
when I wanted to use Java 5 I get question marks
and when I used the servlets which I compiled on jdk1.3 in tomcat 5.5.8  I need 
to adjust the encoding each time I request the servlet to windows-1256.
what's the problem of the encoding in the new versions of Java and tomcat?
I noticed the internationalization in the tomcat contains
tomcat-i18n-en.jar,tomcat-i18n-fr.jar,tomcat-i18n-ja.jar,tomcat-i18n-es.jar
is the problem that I need tomcat-i18n-ar.jar? and if so, how to get it?
Hope I explained the problem in obvious way.
I can't continue using tomcat 4.0.6 cause I always have dbconnection failure as 
I use jndi DataSource, but I found tomcat 5.5.8 is more stable.
Please I need help
Thanks,


Re: Arabic encoding

2005-02-23 Thread Fadwa Barham
hi,
thanks for your reply,
I tried using in my servlet
res.setContentType(text/html; charset=UTF-8)
but I didn't have arabic when I compiled it with jdk1.3, and I could't 
adjust the encoding from the internet explorer as I did when I don't use 
res.setContentType(text/html; charset=UTF-8), and I also tried 
res.setContentType(text/html; charset=windows-1256) and I get all the 
arabic data in the servlet and the database question marks.

I noticed something: when I compile the servlet using Java 5 and write in 
the servlet
res.setContentType(text/html; charset=UTF-8) or
res.setContentType(text/html; charset=windows-1256)
without using
meta http-equiv=Content-Language content=ar-sa
META http-equiv=Content-Type content=text/html;charset=windows-1256
I get the words I wrote in the servlet in arabic correct but the data from 
the database in question mark and also if the servlet has a form, when I 
submit the data I get the phrase also in question mark.
and when I used
req.setCharacterEncoding(utf-8) or 
req.setCharacterEncoding(windows-1256) or
meta http-equiv=Content-Language content=ar-sa
META http-equiv=Content-Type content=text/html;charset=windows-1256
I have the form phrase in arabic but the database cannot realize the 
encoding and return 0 results.
thanks,
Fadwa

- Original Message - 
From: Allistair Crossley [EMAIL PROTECTED]
To: Tomcat Users List tomcat-user@jakarta.apache.org
Sent: Wednesday, February 23, 2005 11:29 AM
Subject: RE: Arabic encoding


Hi,
HTML meta tags won't help you.
Take a look at response.setCharacterEncoding(UTF-8) and JSP page 
directive for contentType

%@ page contentType=text/html; charset=UTF-8 %
Replace UTF-8 with the charset for Arabic and see if that helps.
Allistair.
-Original Message-
From: Fadwa Barham [mailto:[EMAIL PROTECTED]
Sent: 23 February 2005 21:20
To: tomcat-user@jakarta.apache.org
Subject: Arabic encoding
Hi,
 I face difficulties with encoding, at first I developed
servlets that connects to oracle database, the oracle
encoding is US7Ascii and it contains arabic data, I used
Java1.3 to write the code and tomcat 4.0.6 to deploy the
servlets, I just needed to get the write encoding of the
servlets, both the data from the database or the messages I
write in the code in arabic, is puting these lines in the servlet
meta http-equiv=Content-Language content=ar-sa
META http-equiv=Content-Type
content=text/html;charset=windows-1256
when I wanted to use Java 5 I get question marks
and when I used the servlets which I compiled on jdk1.3 in
tomcat 5.5.8  I need to adjust the encoding each time I
request the servlet to windows-1256.
what's the problem of the encoding in the new versions of
Java and tomcat?
I noticed the internationalization in the tomcat contains
tomcat-i18n-en.jar,tomcat-i18n-fr.jar,tomcat-i18n-ja.jar,tomca
t-i18n-es.jar
is the problem that I need tomcat-i18n-ar.jar? and if so, how
to get it?
Hope I explained the problem in obvious way.
I can't continue using tomcat 4.0.6 cause I always have
dbconnection failure as I use jndi DataSource, but I found
tomcat 5.5.8 is more stable.
Please I need help
Thanks,

FONT SIZE=1 FACE=VERDANA,ARIAL COLOR=BLUE
---
QAS Ltd.
Developers of QuickAddress Software
a href=http://www.qas.com;www.qas.com/a
Registered in England: No 2582055
Registered in Australia: No 082 851 474
---
/FONT
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]