Tomcat strips CRLFs from the generated page

2014-01-13 Thread Asok Chattopadhyay
Hi,

My servlet generates a page containing embedded JavaScript and sometimes
the page received in the browser comes with CRLFs stripped from the text,
starting at some point in the text. This creates a big problem if the
script contains CRLF as statement separator instead of semi-colon. It's
strange that not the entire text is stripped. Say, the first 150 lines
comes as it is, whereas starting from line 151, all the CRLFs are stripped.
It is fairly consistent for the same page.

I am using Tomcat 6.0.37.

Why does it happen? Is anything in the text triggers this? Is there a way
to overcome this problem, as I don't have control over the actual content?


Thanks in advance.

Here is the example.


LINE 148:script type=text/javascript
SRC=html/scripts/combotext.js/script

LINE 149:script type=text/javascript
SRC=html/scripts/datepicker.js/script

LINE 150:script type=text/javascript
SRC=html/scripts/combo.js/script

LINE 151:script type=text/javascript
SRC=html/scripts/calc.js/scriptscript type=text/javascript
SRC=html/scripts/dream.js/scriptscript language=javascript
type=text/javascriptvar buttonfunction
clicked(b){button=b.value}function submitit(form){if
(button==Details){form.page.value = opcdtform.searchbutton.value =
Top}}function pickProduct(link, cus){if
(navigator.appName.indexOf(Netscape) =
0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
false}/script/headbody
onload=topBottom();move_caret('one','xcrnnum');
style=margin:0;padding:0;!--div id=darkBackgroundLayer
class=darkenBackground ...


Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Daniel Mikusa
On Jan 13, 2014, at 6:09 AM, Asok Chattopadhyay da.a...@gmail.com wrote:

 Hi,
 
 My servlet generates a page containing embedded JavaScript and sometimes
 the page received in the browser comes with CRLFs stripped from the text,
 starting at some point in the text. This creates a big problem if the
 script contains CRLF as statement separator instead of semi-colon. It's
 strange that not the entire text is stripped. Say, the first 150 lines
 comes as it is, whereas starting from line 151, all the CRLFs are stripped.
 It is fairly consistent for the same page.

Sounds like an application / servlet error.  Have you tried hooking up a 
debugger and stepping through your code?

Also, do you see this consistently across all servlets in your app or just one?

 
 I am using Tomcat 6.0.37.
 
 Why does it happen? Is anything in the text triggers this? Is there a way
 to overcome this problem, as I don't have control over the actual content?

Seems unlikely that Tomcat would be doing this.  Check your servlet code.  
Check if you have any filters in your application, perhaps one is modifying the 
content.

Dan

 
 
 Thanks in advance.
 
 Here is the example.
 
 
 LINE 148:script type=text/javascript
 SRC=html/scripts/combotext.js/script
 
 LINE 149:script type=text/javascript
 SRC=html/scripts/datepicker.js/script
 
 LINE 150:script type=text/javascript
 SRC=html/scripts/combo.js/script
 
 LINE 151:script type=text/javascript
 SRC=html/scripts/calc.js/scriptscript type=text/javascript
 SRC=html/scripts/dream.js/scriptscript language=javascript
 type=text/javascriptvar buttonfunction
 clicked(b){button=b.value}function submitit(form){if
 (button==Details){form.page.value = opcdtform.searchbutton.value =
 Top}}function pickProduct(link, cus){if
 (navigator.appName.indexOf(Netscape) =
 0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
 false}/script/headbody
 onload=topBottom();move_caret('one','xcrnnum');
 style=margin:0;padding:0;!--div id=darkBackgroundLayer
 class=darkenBackground ...


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: serialization and newest tomcat

2014-01-13 Thread Daniel Mikusa
On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote:

I haven't been following this thread, but I wanted to clarify a couple comments 
here just to make sure someone reading this in the future doesn't get the wrong 
ideas.

 serialization causes some problems in apache-tomcat-7.0.35

No.  What causes problems is when application objects are placed in the session 
and they are not serializable.  This happens because, by default, Tomcat will 
try to save your session data when it restarts.  It does this by serializing 
the data to disk.  Then when it restarts, it deserializes the data and restores 
the sessions.

  
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts

The only other reason why your sessions would need to be serializable is if 
you're using clustering (i.e. you add the distributable tag to web.xml).

 I have several applications and run on fedora linux. I have used many 
 releases of fedora and tomcat.
 
 My applications are characterized by
a) all use a DB (firebird)
b) all use both jsp and java servlets
c) all use transient java beans for a round of interaction (user request 
 - user response)
d) all have 1 or more session java beans for each user (login - logout)
e) all have 1 or more application beans (initialized at startup, can 
 refresh, passed around)
f) all have an application specific jar and share a common code jar
 
 Long ago I added serialization to almost all of the java beans to stop tomcat 
 whining in the catalina.out file. This worked just fine until the most recent 
 tomcat release.
 
 On my development machine, java changes build new jars and apache/tomcat must 
 be restarted to work right. Starting with the new release, problems with 
 connections happened.
 
 After research, I discovered that the applications were going nuts with 
 connection requests and xinetd was shutting down the connection factory 
 service. It took a 30 minute wait (or reboot) to fix this problem. My guess 
 is that the application wide beans were not only being made fresh as always 
 happens (they use one connection each to initialize), but that the serialized 
 versions were coming back up and trying to refresh causing lots of strange 
 connections to be created (if one is not passed, one is made and there are 
 many routines each needing a connection).

I'm not going to pretend to fully understand how your application works, but 
from what I took of this explanation it sounds like your application is 
stuffing a lot of unnecessary things into the session.  Limiting that or taking 
a closer look at how those objects are being serialized is probably something 
you should consider.

 
 To solve this problem, I stopped serialization. This solved the problem.

This certainly works, however it's worth nothing that you'll lose any session 
data when you restart Tomcat.  For development that's fine, but in production 
you might not want to do that.  I guess it depends on your app and what's in 
the sessions though.

 
 From the notes I got from others (thanks Mark and ...):
 
 serialization can be stopped by putting this in many places

The many places are context files.  There are several locations where you can 
configure your application's context.

 - here is one:
appname/META-INF/context.xml
 
Manager pathname= /

Again, just watch out as this will prohibit Tomcat from saving session data on 
restart.  In other words, all session data is going to be lost on restart.

Dan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Asok Chattopadhyay
I checked the string, say, s, just before and after writing it to the 
PrintWriter.

PrintWriter out=response.getWriter();
Print(before=+s);
out.println(s);
out.flush();
out.close();
Print(after=+s);

where Print is a static method printing on the log file localhost...log

And the log shows no change. Obviously it looks like whatever is happening is 
happening in out.println.



Sent from my iPhone

On 13 Jan, 2014, at 8:48 PM, Daniel Mikusa dmik...@gopivotal.com wrote:

 On Jan 13, 2014, at 6:09 AM, Asok Chattopadhyay da.a...@gmail.com wrote:
 
 Hi,
 
 My servlet generates a page containing embedded JavaScript and sometimes
 the page received in the browser comes with CRLFs stripped from the text,
 starting at some point in the text. This creates a big problem if the
 script contains CRLF as statement separator instead of semi-colon. It's
 strange that not the entire text is stripped. Say, the first 150 lines
 comes as it is, whereas starting from line 151, all the CRLFs are stripped.
 It is fairly consistent for the same page.
 
 Sounds like an application / servlet error.  Have you tried hooking up a 
 debugger and stepping through your code?
 
 Also, do you see this consistently across all servlets in your app or just 
 one?
 
 
 I am using Tomcat 6.0.37.
 
 Why does it happen? Is anything in the text triggers this? Is there a way
 to overcome this problem, as I don't have control over the actual content?
 
 Seems unlikely that Tomcat would be doing this.  Check your servlet code.  
 Check if you have any filters in your application, perhaps one is modifying 
 the content.
 
 Dan
 
 
 
 Thanks in advance.
 
 Here is the example.
 
 
 LINE 148:script type=text/javascript
 SRC=html/scripts/combotext.js/script
 
 LINE 149:script type=text/javascript
 SRC=html/scripts/datepicker.js/script
 
 LINE 150:script type=text/javascript
 SRC=html/scripts/combo.js/script
 
 LINE 151:script type=text/javascript
 SRC=html/scripts/calc.js/scriptscript type=text/javascript
 SRC=html/scripts/dream.js/scriptscript language=javascript
 type=text/javascriptvar buttonfunction
 clicked(b){button=b.value}function submitit(form){if
 (button==Details){form.page.value = opcdtform.searchbutton.value =
 Top}}function pickProduct(link, cus){if
 (navigator.appName.indexOf(Netscape) =
 0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
 false}/script/headbody
 onload=topBottom();move_caret('one','xcrnnum');
 style=margin:0;padding:0;!--div id=darkBackgroundLayer
 class=darkenBackground ...
 
 
 -
 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



Re: serialization and newest tomcat

2014-01-13 Thread Ray Holme
OK, that makes perfect sense. We are NOT talking about SESSION objects (where I 
am defining session as login to logout of a USER as I mentioned before, perhaps 
you are defining this as while tomcat is up - I can see either def.). These 
type beans are all fine, but I would actually never want them serialized if 
Tomcat restarts as I would want the user to log back in for a lot of reasons 
(but no damage would be caused if they were serialized).

I am talking about java beans that are part of the application and shared 
information available to all users. These MUST be initialized at startup (they 
are) and OLD serial copies are defunct (dangerous as they cause crazy 
connections to happen) when tomcat is restarted.

S - here is the question:

I would like to allow serialization, but tell Tomcat that certain beans should 
NOT be resurrected without me getting warnings in the log file when I don't 
mark them as serialisable.

IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?

Right now, I have stopped warnings but caused other problems.





On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com 
wrote:
 
On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote:

I haven't been following this thread, but I wanted to clarify a couple comments 
here just to make sure someone reading this in the future doesn't get the wrong 
ideas.

 serialization causes some problems in apache-tomcat-7.0.35

No.  What causes problems is when application objects are placed in the session 
and they are not serializable.  This happens because, by default, Tomcat will 
try to save your session data when it restarts.  It does this by serializing 
the data to disk.  Then when it restarts, it deserializes the data and restores 
the sessions.

  
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts

The only other reason why your sessions would need to be serializable is if 
you're using clustering (i.e. you add the distributable tag to web.xml).

 I have several applications and run on fedora linux. I have used many 
 releases of fedora and tomcat.
 
 My applications are characterized by
    a) all use a DB (firebird)
    b) all use both jsp and java servlets
    c) all use transient java beans for a round of interaction (user request 
- user response)
    d) all have 1 or more session java beans for each user (login - logout)
    e) all have 1 or more application beans (initialized at startup, can 
refresh, passed around)
    f) all have an application specific jar and share a common code jar
 
 Long ago I added serialization to almost all of the java beans to stop tomcat 
 whining in the catalina.out file. This worked just fine until the most recent 
 tomcat release.
 
 On my development machine, java changes build new jars and apache/tomcat must 
 be restarted to work right. Starting with the new release, problems with 
 connections happened.
 
 After research, I discovered that the applications were going nuts with 
 connection requests and xinetd was shutting down the connection factory 
 service. It took a 30 minute wait (or reboot) to fix this problem. My guess 
 is that the application wide beans were not only being made fresh as always 
 happens (they use one connection each to initialize), but that the serialized 
 versions were coming back up and trying to refresh causing lots of strange 
 connections to be created (if one is not passed, one is made and there are 
 many routines each needing a connection).

I'm not going to pretend to fully understand how your application works, but 
from what I took of this explanation it sounds like your application is 
stuffing a lot of unnecessary things into the session.  Limiting that or taking 
a closer look at how those objects are being serialized is probably something 
you should consider.

 
 To solve this problem, I stopped serialization. This solved the problem.

This certainly works, however it's worth nothing that you'll lose any session 
data when you restart Tomcat.  For development that's fine, but in production 
you might not want to do that.  I guess it depends on your app and what's in 
the sessions though.

 
 From the notes I got from others (thanks Mark and ...):
 
 serialization can be stopped by putting this in many places

The many places are context files.  There are several locations where you can 
configure your application's context.


 - here is one:
    appname/META-INF/context.xml
 
    Manager pathname= /

Again, just watch out as this will prohibit Tomcat from saving session data on 
restart.  In other words, all session data is going to be lost on restart.

Dan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Daniel Mikusa
On Jan 13, 2014, at 8:26 AM, Asok Chattopadhyay da.a...@gmail.com wrote:

 I checked the string, say, s, just before and after writing it to the 
 PrintWriter.
 
 PrintWriter out=response.getWriter();
 Print(before=+s);
 out.println(s);
 out.flush();
 out.close();
 Print(after=+s);
 
 where Print is a static method printing on the log file localhost...log
 
 And the log shows no change. Obviously it looks like whatever is happening is 
 happening in out.println.

No, not necessarily.  It is quite possible for a servlet Filter to modify what 
you're writing to the output stream.  Does your application have any filters in 
place?

Also, can you provide a demo servlet that replicates this behavior?

Thanks

Dan

 
 
 
 Sent from my iPhone
 
 On 13 Jan, 2014, at 8:48 PM, Daniel Mikusa dmik...@gopivotal.com wrote:
 
 On Jan 13, 2014, at 6:09 AM, Asok Chattopadhyay da.a...@gmail.com wrote:
 
 Hi,
 
 My servlet generates a page containing embedded JavaScript and sometimes
 the page received in the browser comes with CRLFs stripped from the text,
 starting at some point in the text. This creates a big problem if the
 script contains CRLF as statement separator instead of semi-colon. It's
 strange that not the entire text is stripped. Say, the first 150 lines
 comes as it is, whereas starting from line 151, all the CRLFs are stripped.
 It is fairly consistent for the same page.
 
 Sounds like an application / servlet error.  Have you tried hooking up a 
 debugger and stepping through your code?
 
 Also, do you see this consistently across all servlets in your app or just 
 one?
 
 
 I am using Tomcat 6.0.37.
 
 Why does it happen? Is anything in the text triggers this? Is there a way
 to overcome this problem, as I don't have control over the actual content?
 
 Seems unlikely that Tomcat would be doing this.  Check your servlet code.  
 Check if you have any filters in your application, perhaps one is modifying 
 the content.
 
 Dan
 
 
 
 Thanks in advance.
 
 Here is the example.
 
 
 LINE 148:script type=text/javascript
 SRC=html/scripts/combotext.js/script
 
 LINE 149:script type=text/javascript
 SRC=html/scripts/datepicker.js/script
 
 LINE 150:script type=text/javascript
 SRC=html/scripts/combo.js/script
 
 LINE 151:script type=text/javascript
 SRC=html/scripts/calc.js/scriptscript type=text/javascript
 SRC=html/scripts/dream.js/scriptscript language=javascript
 type=text/javascriptvar buttonfunction
 clicked(b){button=b.value}function submitit(form){if
 (button==Details){form.page.value = opcdtform.searchbutton.value =
 Top}}function pickProduct(link, cus){if
 (navigator.appName.indexOf(Netscape) =
 0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
 false}/script/headbody
 onload=topBottom();move_caret('one','xcrnnum');
 style=margin:0;padding:0;!--div id=darkBackgroundLayer
 class=darkenBackground ...
 
 
 -
 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
 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Asok Chattopadhyay
No, I don't have any filter, except for a session counter listener. I am going 
to make a demo servlet and post it soon once I am back at home,

Thanks Dan. I really appreciate your help,

Sent from my iPhone

On 13 Jan, 2014, at 9:36 PM, Daniel Mikusa dmik...@gopivotal.com wrote:

 On Jan 13, 2014, at 8:26 AM, Asok Chattopadhyay da.a...@gmail.com wrote:
 
 I checked the string, say, s, just before and after writing it to the 
 PrintWriter.
 
 PrintWriter out=response.getWriter();
 Print(before=+s);
 out.println(s);
 out.flush();
 out.close();
 Print(after=+s);
 
 where Print is a static method printing on the log file localhost...log
 
 And the log shows no change. Obviously it looks like whatever is happening 
 is happening in out.println.
 
 No, not necessarily.  It is quite possible for a servlet Filter to modify 
 what you're writing to the output stream.  Does your application have any 
 filters in place?
 
 Also, can you provide a demo servlet that replicates this behavior?
 
 Thanks
 
 Dan
 
 
 
 
 Sent from my iPhone
 
 On 13 Jan, 2014, at 8:48 PM, Daniel Mikusa dmik...@gopivotal.com wrote:
 
 On Jan 13, 2014, at 6:09 AM, Asok Chattopadhyay da.a...@gmail.com wrote:
 
 Hi,
 
 My servlet generates a page containing embedded JavaScript and sometimes
 the page received in the browser comes with CRLFs stripped from the text,
 starting at some point in the text. This creates a big problem if the
 script contains CRLF as statement separator instead of semi-colon. It's
 strange that not the entire text is stripped. Say, the first 150 lines
 comes as it is, whereas starting from line 151, all the CRLFs are stripped.
 It is fairly consistent for the same page.
 
 Sounds like an application / servlet error.  Have you tried hooking up a 
 debugger and stepping through your code?
 
 Also, do you see this consistently across all servlets in your app or just 
 one?
 
 
 I am using Tomcat 6.0.37.
 
 Why does it happen? Is anything in the text triggers this? Is there a way
 to overcome this problem, as I don't have control over the actual content?
 
 Seems unlikely that Tomcat would be doing this.  Check your servlet code.  
 Check if you have any filters in your application, perhaps one is modifying 
 the content.
 
 Dan
 
 
 
 Thanks in advance.
 
 Here is the example.
 
 
 LINE 148:script type=text/javascript
 SRC=html/scripts/combotext.js/script
 
 LINE 149:script type=text/javascript
 SRC=html/scripts/datepicker.js/script
 
 LINE 150:script type=text/javascript
 SRC=html/scripts/combo.js/script
 
 LINE 151:script type=text/javascript
 SRC=html/scripts/calc.js/scriptscript type=text/javascript
 SRC=html/scripts/dream.js/scriptscript language=javascript
 type=text/javascriptvar buttonfunction
 clicked(b){button=b.value}function submitit(form){if
 (button==Details){form.page.value = opcdtform.searchbutton.value =
 Top}}function pickProduct(link, cus){if
 (navigator.appName.indexOf(Netscape) =
 0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
 false}/script/headbody
 onload=topBottom();move_caret('one','xcrnnum');
 style=margin:0;padding:0;!--div id=darkBackgroundLayer
 class=darkenBackground ...
 
 
 -
 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
 
 
 
 -
 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



Re: serialization and newest tomcat

2014-01-13 Thread Ray Holme
Oh, I missed one comment from Daniel before (embedded and I did not see on the 
first pass, sorry).

No, you don't know the application so I would like to explain that some 
information kept in the shared application beans is very static, needs to be 
loaded from the DB and is used everywhere by every user. The number of hits to 
the DB would quadruple (at minimum) without these small tables being in memory. 
I waste maybe 5k of memory to reduce DB use in an active system and speed up 
user response time. This would be silly for a system that it NOT active.




On Monday, January 13, 2014 8:38 AM, Ray Holme rayho...@yahoo.com wrote:
 
OK, that makes perfect sense. We are NOT talking about SESSION objects (where I 
am defining session as login to logout of a USER as I mentioned before, perhaps 
you are defining this as while tomcat is up - I can see either def.). These 
type beans are all fine, but I would actually never want them serialized if 
Tomcat restarts as I would want the user to log back in for a lot of reasons 
(but no damage would be caused if they were serialized).

I am talking about java beans that are part of the application and shared 
information available to all users. These MUST be initialized at startup (they 
are) and OLD serial copies are defunct (dangerous as they cause crazy 
connections to happen) when tomcat is restarted.

S - here is the question:

I would like to allow serialization, but tell Tomcat that certain beans should 
NOT be resurrected without me getting warnings in the log file when I don't 
mark them as serialisable.

IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?

Right now, I have stopped warnings but caused other problems.






On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com 
wrote:

On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote:

I haven't been following this thread, but I wanted to clarify a couple comments 
here just to make sure someone reading this in the future doesn't get the wrong 
ideas.

 serialization causes some problems in apache-tomcat-7.0.35

No.  What causes problems is when application objects are placed in the session 
and they are not serializable.  This happens because, by default, Tomcat will 
try to save your session data when it restarts.  It does this by serializing 
the data to disk.  Then when it restarts, it deserializes the data and restores 
the sessions.

  
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts

The only other reason why your sessions would need to be serializable is if 
you're using clustering (i.e. you add the distributable tag to web.xml).

 I have several applications and run on fedora linux. I have used many 
 releases of fedora and tomcat.
 
 My applications are characterized by
    a) all use a DB (firebird)
    b) all use both jsp and java servlets
    c) all use transient java beans for a round of interaction (user request 
- user response)
    d) all have 1 or more session java beans for each user (login - logout)
    e) all have 1 or more application beans (initialized at startup, can 
refresh, passed around)
    f) all have an application specific jar and share a common code jar
 
 Long ago I added serialization to almost all of the java beans to stop tomcat 
 whining in the catalina.out file. This worked just fine until the most recent 
 tomcat release.
 
 On my development machine, java changes build new jars and apache/tomcat must 
 be restarted to work right. Starting with the new release, problems with 
 connections happened.
 
 After research, I discovered that the applications were going nuts with 
 connection requests and xinetd was shutting down the connection factory 
 service. It took a 30 minute wait (or reboot) to fix this problem. My guess 
 is that the application wide beans were not only being made fresh as always 
 happens (they use one connection each to initialize), but that the serialized 
 versions were coming back up and trying to refresh causing lots of strange 
 connections to be created (if one is not passed, one is made and there are 
 many routines each needing a connection).

I'm not going to pretend to fully understand how your application works, but 
from what I took of this explanation it sounds like your application is 
stuffing a lot of unnecessary things into the session.  Limiting that or taking 
a closer look at how those objects are being serialized is probably something 
you should consider.

 
 To solve this problem, I stopped serialization. This solved the problem.

This certainly works, however it's worth nothing that you'll lose any session 
data when you restart Tomcat.  For development that's fine, but in production 
you might not want to do that.  I guess it depends on your app and what's in 
the sessions though.

 
 From the notes I got from others (thanks Mark and ...):
 
 serialization can be stopped by putting this in many places

The many places are 

Re: serialization and newest tomcat

2014-01-13 Thread Daniel Mikusa
On Jan 13, 2014, at 8:37 AM, Ray Holme rayho...@yahoo.com wrote:

 OK, that makes perfect sense. We are NOT talking about SESSION objects (where 
 I am defining session as login to logout of a USER as I mentioned before, 
 perhaps you are defining this as while tomcat is up - I can see either 
 def.). These type beans are all fine, but I would actually never want them 
 serialized if Tomcat restarts as I would want the user to log back in for a 
 lot of reasons (but no damage would be caused if they were serialized).

I'm referring to HttpSession.

  http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html

Any thing you store on the session through the Servlet API will be persisted by 
Tomcat when it shuts down and restored when it restarts (unless you disable 
this behavior as you have).  This allows you to restart Tomcat and not lose 
session data.

If you want to see what your application is storing in the session, take a look 
at the Manager application.  It allows you to browse through active sessions 
and view what has been stored there.

 I am talking about java beans that are part of the application and shared 
 information available to all users. These MUST be initialized at startup 
 (they are) and OLD serial copies are defunct (dangerous as they cause crazy 
 connections to happen) when tomcat is restarted.

Not following you here.  Tomcat only serializes what you put into a session 
(javax.servlet.HttpSession).  Anything else is up to your application.

 S - here is the question:
 
 I would like to allow serialization,

Ok.  Make sure any object you put into the session implements Serializable.

 but tell Tomcat that certain beans should NOT be resurrected

Certainly one option is to not put them in the session, but you do have other 
options.  See last comment.

 without me getting warnings in the log file when I don't mark them as 
 serializable.

They *must* be serializable.  Otherwise you're going to get an exception.  This 
is a requirement of Java serialization.

 
 IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?
 
 Right now, I have stopped warnings but caused other problems.

As I've mentioned, your beans must implement Serializable or they won't be able 
to be serialized and you'll see error.  This is not an issue with Tomcat.  It's 
a requirement of Java serialization.  Tomcat uses Java serialization to persist 
your session data between restarts so it inherits this requirement.  

I would suggest that you look into how Java serializes your objects.  If you 
don't like the default behavior, it provides you with the ability to control 
that process.  One example, if you want to prohibit a field from being 
serialized you can mark it transient.

Dan

 
 
 
 
 
 On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com 
 wrote:
 
 On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote:
 
 I haven't been following this thread, but I wanted to clarify a couple 
 comments here just to make sure someone reading this in the future doesn't 
 get the wrong ideas.
 
 serialization causes some problems in apache-tomcat-7.0.35
 
 No.  What causes problems is when application objects are placed in the 
 session and they are not serializable.  This happens because, by default, 
 Tomcat will try to save your session data when it restarts.  It does this by 
 serializing the data to disk.  Then when it restarts, it deserializes the 
 data and restores the sessions.
 
   
 http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts
 
 The only other reason why your sessions would need to be serializable is if 
 you're using clustering (i.e. you add the distributable tag to web.xml).
 
 I have several applications and run on fedora linux. I have used many 
 releases of fedora and tomcat.
 
 My applications are characterized by
 a) all use a DB (firebird)
 b) all use both jsp and java servlets
 c) all use transient java beans for a round of interaction (user 
 request - user response)
 d) all have 1 or more session java beans for each user (login - logout)
 e) all have 1 or more application beans (initialized at startup, can 
 refresh, passed around)
 f) all have an application specific jar and share a common code jar
 
 Long ago I added serialization to almost all of the java beans to stop 
 tomcat whining in the catalina.out file. This worked just fine until the 
 most recent tomcat release.
 
 On my development machine, java changes build new jars and apache/tomcat 
 must be restarted to work right. Starting with the new release, problems 
 with connections happened.
 
 After research, I discovered that the applications were going nuts with 
 connection requests and xinetd was shutting down the connection factory 
 service. It took a 30 minute wait (or reboot) to fix this problem. My guess 
 is that the application wide beans were not only being made fresh as always 
 happens (they 

Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread André Warnier

Asok Chattopadhyay wrote:

Hi,

My servlet generates a page containing embedded JavaScript and sometimes
the page received in the browser comes with CRLFs stripped from the text,
starting at some point in the text. This creates a big problem if the
script contains CRLF as statement separator instead of semi-colon. It's
strange that not the entire text is stripped. Say, the first 150 lines
comes as it is, whereas starting from line 151, all the CRLFs are stripped.
It is fairly consistent for the same page.

I am using Tomcat 6.0.37.

Why does it happen? Is anything in the text triggers this? Is there a way
to overcome this problem, as I don't have control over the actual content?


Thanks in advance.

Here is the example.


LINE 148:script type=text/javascript
SRC=html/scripts/combotext.js/script

LINE 149:script type=text/javascript
SRC=html/scripts/datepicker.js/script

LINE 150:script type=text/javascript
SRC=html/scripts/combo.js/script

LINE 151:script type=text/javascript
SRC=html/scripts/calc.js/scriptscript type=text/javascript
SRC=html/scripts/dream.js/scriptscript language=javascript
type=text/javascriptvar buttonfunction
clicked(b){button=b.value}function submitit(form){if
(button==Details){form.page.value = opcdtform.searchbutton.value =
Top}}function pickProduct(link, cus){if
(navigator.appName.indexOf(Netscape) =
0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
false}/script/headbody
onload=topBottom();move_caret('one','xcrnnum');
style=margin:0;padding:0;!--div id=darkBackgroundLayer
class=darkenBackground ...



Hi.
I have to disregard your example above, because once reformated by the various email 
agents in-between, there is no telling anymore what the original was like.


In general, are you not just victim of the following circumstances ?

In HTML (and I suppose that this also includes embedded script../script sections, an 
end of line is composed of 2 characters : a carriage return (CR) and a line feed (LF).


When you are running a java program, the println function probably appends an end of 
line sequence to what you are printing, but this end of line sequence depends on the 
platform on which your java program runs :

- on a Windows system, the end of line sequence would be CR + LF
- on a Unix/Linux system, it will be just LF
- on a Mac system, it would be just CR

So depending on what platform your server is running, and on what platform the client is 
running, they may interpret the result differently.


In other words, if your java application is outputting HTML and/or javascript, you should 
probably not be using println.  You should be using print, and explicitly append a CR 
and LF to your output lines.  (\r\n ?).



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Mod_jk error

2014-01-13 Thread Alex Lucard
Thank you so much i have it working now i had to change the httpd.com from
JkMount /Hello/*loadbalancer1
To
JkMount /Hello*workspace1
On Jan 12, 2014 9:31 PM, 侯树成 chain...@gmail.com wrote:

 Hi, Alex
 What is your mod_jk.conf file that used for mod_jk configuration.

 You can config it as blow:
 LoadModule jk_module modules/mod_jk.so
 JkWorkersFile  conf/workers.properties
 JkLogFile logs/mod_jk.log
 JkLogLevel error
 JkLogStampFormat [%a %b %d %H:%M:%S %Y]
 JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
 JkMount /test_status mystatus
 JkMount /hello*loadbalancer1

 or Just as your configuration now, but add the JkMount to http.conf. The
 JkMount /hello* loadbalancer1 will send all request start with hello  to
 loadbalancer1

 Hope to help you.


 2014/1/11 Mark Eggers its_toas...@yahoo.com

  On 1/10/2014 2:53 PM, Alex Lucard wrote:
 
  .
  On Jan 10, 2014 5:00 PM, Alex Lucard priest.luc...@gmail.com wrote:
 
   I am running CentOS 6.5 and tomcat 7
  I cannot get the mod_jk to work
  I have a JSP page on this server and if you go to localhost:8080/Hello
 it
  will work but if I just go to localhost/Hello The requested URL /Hello
  was
  not found on this server.
 
  I have apache2 and tomcat 7 install both work.
  Here is the part I added to the httpd.conf file
 
  # Load the mod_jk module.
  LoadModule jk_module /usr/lib64/httpd/modules/mod_jk.so
  JkWorkersFile /etc/httpd/conf/workers.properties
  jkLogFile /var/log/mod_jk.log
  JkLogLevellevel
  JkLogStampFormat [%a %b %d %H:%M:%S %Y] 
 
  My workers.properties file at /etc/httpd/conf/workers.properties
  worker.list=worker1
  worker.worker1.type=ajp13
  worker.worker1.port=8009
  worker.worker1.host=localhost
  #worker.worker1.lbfactor=1
 
 
  My error log file /var/log/mod_jk.log
  [Fri Jan 10 15:19:22 2014] [1854:140509786134496] [info]
  init_jk::mod_jk.c
  (3365): mod_jk/1.2.37 initialized
  [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [error]
  ajp_validate::jk_ajp_common.c (2696): worker worker1 can't resolve
 tomcat
  address localhost
  [Fri Jan 10 15:19:23 2014] [1855:140509786134496] [info]
  init_jk::mod_jk.c
  (3365): mod_jk/1.2.37 initialized
 
 
 
  What happens when you type the following from the command line:
 
  dig localhost
 
  As a workaround, replace localhost with 127.0.0.1.
 
  . . . . just my two cents
  /mde/
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 
 



Re: serialization and newest tomcat

2014-01-13 Thread Johan Compagner


 IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?

 Right now, I have stopped warnings but caused other problems.


just don't add those beans to a session or if you do add them make sure
that they are in containers and that those fields are transient
then those fields (beans) are not serialized and they are null when they
are deserialized (so you need to refill them if they are needed)


-- 
Johan Compagner
Servoy


Re: serialization and newest tomcat

2014-01-13 Thread Ray Holme
I have (in the past) dealt with transient so OK, makes sense.
Not familiar with putting in container to shield from Apache serialization.

Will look for writeup. Thanks.





On Monday, January 13, 2014 10:12 AM, Johan Compagner jcompag...@servoy.com 
wrote:
 

IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?

Right now, I have stopped warnings but caused other problems.




just don't add those beans to a session or if you do add them make sure that 
they are in containers and that those fields are transient
then those fields (beans) are not serialized and they are null when they are 
deserialized (so you need to refill them if they are needed)

-- 
Johan Compagner
Servoy

Re: serialization and newest tomcat

2014-01-13 Thread Daniel Mikusa
On Jan 13, 2014, at 9:02 AM, Ray Holme rayho...@yahoo.com wrote:

 Oh, I missed one comment from Daniel before (embedded and I did not see on 
 the first pass, sorry).
 
 No, you don't know the application so I would like to explain that some 
 information kept in the shared application beans is very static, needs to 
 be loaded from the DB and is used everywhere by every user. The number of 
 hits to the DB would quadruple (at minimum) without these small tables being 
 in memory. I waste maybe 5k of memory to reduce DB use in an active system 
 and speed up user response time. This would be silly for a system that it NOT 
 active.

This is fine and seems to make good sense.  You certainly don't want to 
overload your DB.  How does this relate to the problem at hand though?  You 
need to provide more concrete details.  How are you loading this information?  
How are you storing this information in memory?  What do you mean by shared 
application beans?  How does this related to sessions and Tomcat serializing 
the data?

Dan

 
 
 
 
 On Monday, January 13, 2014 8:38 AM, Ray Holme rayho...@yahoo.com wrote:
 
 OK, that makes perfect sense. We are NOT talking about SESSION objects (where 
 I am defining session as login to logout of a USER as I mentioned before, 
 perhaps you are defining this as while tomcat is up - I can see either 
 def.). These type beans are all fine, but I would actually never want them 
 serialized if Tomcat restarts as I would want the user to log back in for a 
 lot of reasons (but no damage would be caused if they were serialized).
 
 I am talking about java beans that are part of the application and shared 
 information available to all users. These MUST be initialized at startup 
 (they are) and OLD serial copies are defunct (dangerous as they cause crazy 
 connections to happen) when tomcat is restarted.
 
 S - here is the question:
 
 I would like to allow serialization, but tell Tomcat that certain beans 
 should NOT be resurrected without me getting warnings in the log file when I 
 don't mark them as serialisable.
 
 IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?
 
 Right now, I have stopped warnings but caused other problems.
 
 
 
 
 
 
 On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com 
 wrote:
 
 On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote:
 
 I haven't been following this thread, but I wanted to clarify a couple 
 comments here just to make sure someone reading this in the future doesn't 
 get the wrong ideas.
 
 serialization causes some problems in apache-tomcat-7.0.35
 
 No.  What causes problems is when application objects are placed in the 
 session and they are not serializable.  This happens because, by default, 
 Tomcat will try to save your session data when it restarts.  It does this by 
 serializing the data to disk.  Then when it restarts, it deserializes the 
 data and restores the sessions.
 
   
 http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts
 
 The only other reason why your sessions would need to be serializable is if 
 you're using clustering (i.e. you add the distributable tag to web.xml).
 
 I have several applications and run on fedora linux. I have used many 
 releases of fedora and tomcat.
 
 My applications are characterized by
 a) all use a DB (firebird)
 b) all use both jsp and java servlets
 c) all use transient java beans for a round of interaction (user 
 request - user response)
 d) all have 1 or more session java beans for each user (login - logout)
 e) all have 1 or more application beans (initialized at startup, can 
 refresh, passed around)
 f) all have an application specific jar and share a common code jar
 
 Long ago I added serialization to almost all of the java beans to stop 
 tomcat whining in the catalina.out file. This worked just fine until the 
 most recent tomcat release.
 
 On my development machine, java changes build new jars and apache/tomcat 
 must be restarted to work right. Starting with the new release, problems 
 with connections happened.
 
 After research, I discovered that the applications were going nuts with 
 connection requests and xinetd was shutting down the connection factory 
 service. It took a 30 minute wait (or reboot) to fix this problem. My guess 
 is that the application wide beans were not only being made fresh as always 
 happens (they use one connection each to initialize), but that the 
 serialized versions were coming back up and trying to refresh causing lots 
 of strange connections to be created (if one is not passed, one is made and 
 there are many routines each needing a connection).
 
 I'm not going to pretend to fully understand how your application works, but 
 from what I took of this explanation it sounds like your application is 
 stuffing a lot of unnecessary things into the session.  Limiting that or 
 taking a closer look at how those objects 

Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Asok Chattopadhyay
I am attaching the Test servlet and the text file that contains the  page.
The Test servlet simply reads the file and sends out to the browser. When I
run this servlet, it strips all CRLFs from line 153 onward.

Thanks.


On Mon, Jan 13, 2014 at 9:57 PM, Asok Chattopadhyay da.a...@gmail.comwrote:

 No, I don't have any filter, except for a session counter listener. I am
 going to make a demo servlet and post it soon once I am back at home,

 Thanks Dan. I really appreciate your help,

 Sent from my iPhone

 On 13 Jan, 2014, at 9:36 PM, Daniel Mikusa dmik...@gopivotal.com wrote:

  On Jan 13, 2014, at 8:26 AM, Asok Chattopadhyay da.a...@gmail.com
 wrote:
 
  I checked the string, say, s, just before and after writing it to the
 PrintWriter.
 
  PrintWriter out=response.getWriter();
  Print(before=+s);
  out.println(s);
  out.flush();
  out.close();
  Print(after=+s);
 
  where Print is a static method printing on the log file localhost...log
 
  And the log shows no change. Obviously it looks like whatever is
 happening is happening in out.println.
 
  No, not necessarily.  It is quite possible for a servlet Filter to
 modify what you're writing to the output stream.  Does your application
 have any filters in place?
 
  Also, can you provide a demo servlet that replicates this behavior?
 
  Thanks
 
  Dan
 
 
 
 
  Sent from my iPhone
 
  On 13 Jan, 2014, at 8:48 PM, Daniel Mikusa dmik...@gopivotal.com
 wrote:
 
  On Jan 13, 2014, at 6:09 AM, Asok Chattopadhyay da.a...@gmail.com
 wrote:
 
  Hi,
 
  My servlet generates a page containing embedded JavaScript and
 sometimes
  the page received in the browser comes with CRLFs stripped from the
 text,
  starting at some point in the text. This creates a big problem if the
  script contains CRLF as statement separator instead of semi-colon.
 It's
  strange that not the entire text is stripped. Say, the first 150 lines
  comes as it is, whereas starting from line 151, all the CRLFs are
 stripped.
  It is fairly consistent for the same page.
 
  Sounds like an application / servlet error.  Have you tried hooking up
 a debugger and stepping through your code?
 
  Also, do you see this consistently across all servlets in your app or
 just one?
 
 
  I am using Tomcat 6.0.37.
 
  Why does it happen? Is anything in the text triggers this? Is there a
 way
  to overcome this problem, as I don't have control over the actual
 content?
 
  Seems unlikely that Tomcat would be doing this.  Check your servlet
 code.  Check if you have any filters in your application, perhaps one is
 modifying the content.
 
  Dan
 
 
 
  Thanks in advance.
 
  Here is the example.
 
 
  LINE 148:script type=text/javascript
  SRC=html/scripts/combotext.js/script
 
  LINE 149:script type=text/javascript
  SRC=html/scripts/datepicker.js/script
 
  LINE 150:script type=text/javascript
  SRC=html/scripts/combo.js/script
 
  LINE 151:script type=text/javascript
  SRC=html/scripts/calc.js/scriptscript type=text/javascript
  SRC=html/scripts/dream.js/scriptscript language=javascript
  type=text/javascriptvar buttonfunction
  clicked(b){button=b.value}function submitit(form){if
  (button==Details){form.page.value = opcdtform.searchbutton.value =
  Top}}function pickProduct(link, cus){if
  (navigator.appName.indexOf(Netscape) =
 
 0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
  false}/script/headbody
  onload=topBottom();move_caret('one','xcrnnum');
  style=margin:0;padding:0;!--div id=darkBackgroundLayer
  class=darkenBackground ...
 
 
  -
  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
 
 
 
  -
  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

Re: serialization and newest tomcat

2014-01-13 Thread David kerber
Another option would be to read them from the db once, at system 
startup, and then keep them static from there.  You're still hitting 
your db, but not on an ongoing basis.





On 1/13/2014 9:02 AM, Ray Holme wrote:

Oh, I missed one comment from Daniel before (embedded and I did not see on the 
first pass, sorry).

No, you don't know the application so I would like to explain that some information kept 
in the shared application beans is very static, needs to be loaded from the 
DB and is used everywhere by every user. The number of hits to the DB would quadruple (at 
minimum) without these small tables being in memory. I waste maybe 5k of memory to reduce 
DB use in an active system and speed up user response time. This would be silly for a 
system that it NOT active.




On Monday, January 13, 2014 8:38 AM, Ray Holme rayho...@yahoo.com wrote:

OK, that makes perfect sense. We are NOT talking about SESSION objects (where I am 
defining session as login to logout of a USER as I mentioned before, perhaps you are 
defining this as while tomcat is up - I can see either def.). These type 
beans are all fine, but I would actually never want them serialized if Tomcat restarts as 
I would want the user to log back in for a lot of reasons (but no damage would be caused 
if they were serialized).

I am talking about java beans that are part of the application and shared 
information available to all users. These MUST be initialized at startup (they are) and 
OLD serial copies are defunct (dangerous as they cause crazy connections to happen) when 
tomcat is restarted.

S - here is the question:

I would like to allow serialization, but tell Tomcat that certain beans should 
NOT be resurrected without me getting warnings in the log file when I don't 
mark them as serialisable.

IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?

Right now, I have stopped warnings but caused other problems.






On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com 
wrote:

On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote:

I haven't been following this thread, but I wanted to clarify a couple comments 
here just to make sure someone reading this in the future doesn't get the wrong 
ideas.


serialization causes some problems in apache-tomcat-7.0.35


No.  What causes problems is when application objects are placed in the session 
and they are not serializable.  This happens because, by default, Tomcat will 
try to save your session data when it restarts.  It does this by serializing 
the data to disk.  Then when it restarts, it deserializes the data and restores 
the sessions.

   
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts

The only other reason why your sessions would need to be serializable is if 
you're using clustering (i.e. you add the distributable tag to web.xml).


I have several applications and run on fedora linux. I have used many releases 
of fedora and tomcat.

My applications are characterized by
 a) all use a DB (firebird)
 b) all use both jsp and java servlets
 c) all use transient java beans for a round of interaction (user request 
- user response)
 d) all have 1 or more session java beans for each user (login - logout)
 e) all have 1 or more application beans (initialized at startup, can 
refresh, passed around)
 f) all have an application specific jar and share a common code jar

Long ago I added serialization to almost all of the java beans to stop tomcat 
whining in the catalina.out file. This worked just fine until the most recent 
tomcat release.

On my development machine, java changes build new jars and apache/tomcat must 
be restarted to work right. Starting with the new release, problems with 
connections happened.

After research, I discovered that the applications were going nuts with 
connection requests and xinetd was shutting down the connection factory 
service. It took a 30 minute wait (or reboot) to fix this problem. My guess is 
that the application wide beans were not only being made fresh as always 
happens (they use one connection each to initialize), but that the serialized 
versions were coming back up and trying to refresh causing lots of strange 
connections to be created (if one is not passed, one is made and there are many 
routines each needing a connection).


I'm not going to pretend to fully understand how your application works, but 
from what I took of this explanation it sounds like your application is 
stuffing a lot of unnecessary things into the session.  Limiting that or taking 
a closer look at how those objects are being serialized is probably something 
you should consider.



To solve this problem, I stopped serialization. This solved the problem.


This certainly works, however it's worth nothing that you'll lose any session 
data when you restart Tomcat.  For development that's fine, but in production 
you might not want to do that.  I 

Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Asok Chattopadhyay
You can see the test servlet working at
http://workshop.dreamapps.com/da/test

Thanks again


On Mon, Jan 13, 2014 at 11:36 PM, Asok Chattopadhyay da.a...@gmail.comwrote:

 I am attaching the Test servlet and the text file that contains the  page.
 The Test servlet simply reads the file and sends out to the browser. When I
 run this servlet, it strips all CRLFs from line 153 onward.

 Thanks.


 On Mon, Jan 13, 2014 at 9:57 PM, Asok Chattopadhyay da.a...@gmail.comwrote:

 No, I don't have any filter, except for a session counter listener. I am
 going to make a demo servlet and post it soon once I am back at home,

 Thanks Dan. I really appreciate your help,

 Sent from my iPhone

 On 13 Jan, 2014, at 9:36 PM, Daniel Mikusa dmik...@gopivotal.com wrote:

  On Jan 13, 2014, at 8:26 AM, Asok Chattopadhyay da.a...@gmail.com
 wrote:
 
  I checked the string, say, s, just before and after writing it to the
 PrintWriter.
 
  PrintWriter out=response.getWriter();
  Print(before=+s);
  out.println(s);
  out.flush();
  out.close();
  Print(after=+s);
 
  where Print is a static method printing on the log file localhost...log
 
  And the log shows no change. Obviously it looks like whatever is
 happening is happening in out.println.
 
  No, not necessarily.  It is quite possible for a servlet Filter to
 modify what you're writing to the output stream.  Does your application
 have any filters in place?
 
  Also, can you provide a demo servlet that replicates this behavior?
 
  Thanks
 
  Dan
 
 
 
 
  Sent from my iPhone
 
  On 13 Jan, 2014, at 8:48 PM, Daniel Mikusa dmik...@gopivotal.com
 wrote:
 
  On Jan 13, 2014, at 6:09 AM, Asok Chattopadhyay da.a...@gmail.com
 wrote:
 
  Hi,
 
  My servlet generates a page containing embedded JavaScript and
 sometimes
  the page received in the browser comes with CRLFs stripped from the
 text,
  starting at some point in the text. This creates a big problem if the
  script contains CRLF as statement separator instead of semi-colon.
 It's
  strange that not the entire text is stripped. Say, the first 150
 lines
  comes as it is, whereas starting from line 151, all the CRLFs are
 stripped.
  It is fairly consistent for the same page.
 
  Sounds like an application / servlet error.  Have you tried hooking
 up a debugger and stepping through your code?
 
  Also, do you see this consistently across all servlets in your app or
 just one?
 
 
  I am using Tomcat 6.0.37.
 
  Why does it happen? Is anything in the text triggers this? Is there
 a way
  to overcome this problem, as I don't have control over the actual
 content?
 
  Seems unlikely that Tomcat would be doing this.  Check your servlet
 code.  Check if you have any filters in your application, perhaps one is
 modifying the content.
 
  Dan
 
 
 
  Thanks in advance.
 
  Here is the example.
 
 
  LINE 148:script type=text/javascript
  SRC=html/scripts/combotext.js/script
 
  LINE 149:script type=text/javascript
  SRC=html/scripts/datepicker.js/script
 
  LINE 150:script type=text/javascript
  SRC=html/scripts/combo.js/script
 
  LINE 151:script type=text/javascript
  SRC=html/scripts/calc.js/scriptscript
 type=text/javascript
  SRC=html/scripts/dream.js/scriptscript language=javascript
  type=text/javascriptvar buttonfunction
  clicked(b){button=b.value}function submitit(form){if
  (button==Details){form.page.value = opcdtform.searchbutton.value
 =
  Top}}function pickProduct(link, cus){if
  (navigator.appName.indexOf(Netscape) =
 
 0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
  false}/script/headbody
  onload=topBottom();move_caret('one','xcrnnum');
  style=margin:0;padding:0;!--div id=darkBackgroundLayer
  class=darkenBackground ...
 
 
  -
  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
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
  For additional commands, e-mail: users-h...@tomcat.apache.org
 





Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Daniel Mikusa
On Jan 13, 2014, at 10:36 AM, Asok Chattopadhyay da.a...@gmail.com wrote:

 I am attaching the Test servlet and the text file that contains the  page. 
 The Test servlet simply reads the file and sends out to the browser. When I 
 run this servlet, it strips all CRLFs from line 153 onward.

Your attachment was stripped from the list.  Can you copy and paste it inline?

Dan

  
 Thanks.
 
 
 On Mon, Jan 13, 2014 at 9:57 PM, Asok Chattopadhyay da.a...@gmail.com wrote:
 No, I don't have any filter, except for a session counter listener. I am 
 going to make a demo servlet and post it soon once I am back at home,
 
 Thanks Dan. I really appreciate your help,
 
 Sent from my iPhone
 
 On 13 Jan, 2014, at 9:36 PM, Daniel Mikusa dmik...@gopivotal.com wrote:
 
  On Jan 13, 2014, at 8:26 AM, Asok Chattopadhyay da.a...@gmail.com wrote:
 
  I checked the string, say, s, just before and after writing it to the 
  PrintWriter.
 
  PrintWriter out=response.getWriter();
  Print(before=+s);
  out.println(s);
  out.flush();
  out.close();
  Print(after=+s);
 
  where Print is a static method printing on the log file localhost...log
 
  And the log shows no change. Obviously it looks like whatever is happening 
  is happening in out.println.
 
  No, not necessarily.  It is quite possible for a servlet Filter to modify 
  what you're writing to the output stream.  Does your application have any 
  filters in place?
 
  Also, can you provide a demo servlet that replicates this behavior?
 
  Thanks
 
  Dan
 
 
 
 
  Sent from my iPhone
 
  On 13 Jan, 2014, at 8:48 PM, Daniel Mikusa dmik...@gopivotal.com wrote:
 
  On Jan 13, 2014, at 6:09 AM, Asok Chattopadhyay da.a...@gmail.com wrote:
 
  Hi,
 
  My servlet generates a page containing embedded JavaScript and sometimes
  the page received in the browser comes with CRLFs stripped from the text,
  starting at some point in the text. This creates a big problem if the
  script contains CRLF as statement separator instead of semi-colon. It's
  strange that not the entire text is stripped. Say, the first 150 lines
  comes as it is, whereas starting from line 151, all the CRLFs are 
  stripped.
  It is fairly consistent for the same page.
 
  Sounds like an application / servlet error.  Have you tried hooking up a 
  debugger and stepping through your code?
 
  Also, do you see this consistently across all servlets in your app or 
  just one?
 
 
  I am using Tomcat 6.0.37.
 
  Why does it happen? Is anything in the text triggers this? Is there a way
  to overcome this problem, as I don't have control over the actual 
  content?
 
  Seems unlikely that Tomcat would be doing this.  Check your servlet code. 
   Check if you have any filters in your application, perhaps one is 
  modifying the content.
 
  Dan
 
 
 
  Thanks in advance.
 
  Here is the example.
 
 
  LINE 148:script type=text/javascript
  SRC=html/scripts/combotext.js/script
 
  LINE 149:script type=text/javascript
  SRC=html/scripts/datepicker.js/script
 
  LINE 150:script type=text/javascript
  SRC=html/scripts/combo.js/script
 
  LINE 151:script type=text/javascript
  SRC=html/scripts/calc.js/scriptscript type=text/javascript
  SRC=html/scripts/dream.js/scriptscript language=javascript
  type=text/javascriptvar buttonfunction
  clicked(b){button=b.value}function submitit(form){if
  (button==Details){form.page.value = opcdtform.searchbutton.value =
  Top}}function pickProduct(link, cus){if
  (navigator.appName.indexOf(Netscape) =
  0){document.one.xinvnum.value=link.textdocument.one.xcus.value=cus.text}else{document.one.xinvnum.value=link.innerTextdocument.one.xcus.value=cus.innerText}return
  false}/script/headbody
  onload=topBottom();move_caret('one','xcrnnum');
  style=margin:0;padding:0;!--div id=darkBackgroundLayer
  class=darkenBackground ...
 
 
  -
  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
 
 
 
  -
  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


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Konstantin Preißer
Hi,

 -Original Message-
 From: Asok Chattopadhyay [mailto:da.a...@gmail.com]
 Sent: Monday, January 13, 2014 4:52 PM
 To: Tomcat Users List
 Subject: Re: Tomcat strips CRLFs from the generated page
 
  I am attaching the Test servlet and the text file that contains the  page.
  The Test servlet simply reads the file and sends out to the browser. When I
  run this servlet, it strips all CRLFs from line 153 onward.
 
  Thanks.

The list strips most attachments. Please upload the files somewhere else and 
post a link to download them.


Regards,
Konstantin Preißer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Oracle Application Server 10g R3 works fine with RK-1048 codepage but Tomcat 7.0.47 does not.

2014-01-13 Thread Тимур Кулибаев
Dears,
I have checked documentation/FAQ/WEB/archives but it didn't help to resolve
the following trouble:
I have a java servlet which is currently deployed on Oracle Application
Server 10g R3 with jdk 1.5u19 on RHEl 5.7 and one works fine with Oracle
Application Server.
The servlet works with Oracle Database which has cyrillic single-byte
codepage CL8MSWIN1251.
The servlet was migrated from Oracle Application Server 10g R3 to Tomcat
7.0.47.
I use Tomcat 7.0.47 with jdk-1.6u38 on RHEl 5.7.
The servlet works fine with Tomcat 7 except only trouble with some
characters displaiyng.

The point is that there is a special language driver for Windows  which
provides Kazakh extension for codepage Windows-1251.
The language driver works in single-byte codepage named RK-1048 which is
almost the same as widely known Windows-1251 codepage.
Only difference between Windows-1251 and RK-1048 is that RK-1048 has
several specific Kazakh letters added (Kazakh alphabet equals Russian
alphabet plus several specific letters of Kazakh language).

The trouble is that specific Kazakh letters are not displaying correctly in
servlet on Tomcat 7 but on Oracle Application Server all specific Kazakh
letters are displayed correctly.
Servlet operates by GET-requests when send data to server.
So in my understanding I must get Tomcat worked in Windows-1251 for
GET-requests. Also, UTF-8 is not suit for me as database is in single-byte
codepage.
From Tomcat 7 documentation:
There are two ways to specify how GET parameters are interpreted:
1.Set the URIEncoding attribute on the Connector element in server.xml to
something specific (e.g. URIEncoding=UTF-8).
2.Set the useBodyEncodingForURI attribute on the Connector element in
server.xml to true. This will cause the Connector to use the request body's
encoding for
GET parameters.

I have tried URIEncoding and useBodyEncodingForURI on http-connector but it
doesn't help.

Connector port=7785 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443
   URIEncoding=Windows-1251
/

or

Connector port=7785 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443
   useBodyEncodingForURI=true
/

or
Connector port=7785 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443
   URIEncoding=Windows-1251
   useBodyEncodingForURI=true
/

Why Oracle Application Server works fine with RK-1048 codepage but Tomcat
7.0.47 does not ?

Kind regards,
Timur


Re: serialization and newest tomcat

2014-01-13 Thread Ray Holme
Nice, I do that for many things, but not all of it. You are right, I probably 
could do that.
Nice food for thought!

:=]





On Monday, January 13, 2014 11:31 AM, Daniel Mikusa dmik...@gopivotal.com 
wrote:
 
On Jan 13, 2014, at 8:37 AM, Ray Holme rayho...@yahoo.com wrote:

 OK, that makes perfect sense. We are NOT talking about SESSION objects (where 
 I am defining session as login to logout of a USER as I mentioned before, 
 perhaps you are defining this as while tomcat is up - I can see either 
 def.). These type beans are all fine, but I would actually never want them 
 serialized if Tomcat restarts as I would want the user to log back in for a 
 lot of reasons (but no damage would be caused if they were serialized).

I'm referring to HttpSession.

  http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSession.html

Any thing you store on the session through the Servlet API will be persisted by 
Tomcat when it shuts down and restored when it restarts (unless you disable 
this behavior as you have).  This allows you to restart Tomcat and not lose 
session data.

If you want to see what your application is storing in the session, take a look 
at the Manager application.  It allows you to browse through active sessions 
and view what has been stored there.

 I am talking about java beans that are part of the application and shared 
 information available to all users. These MUST be initialized at startup 
 (they are) and OLD serial copies are defunct (dangerous as they cause crazy 
 connections to happen) when tomcat is restarted.

Not following you here.  Tomcat only serializes what you put into a session 
(javax.servlet.HttpSession).  Anything else is up to your application.

 S - here is the question:
 
 I would like to allow serialization,

Ok.  Make sure any object you put into the session implements Serializable.

 but tell Tomcat that certain beans should NOT be resurrected

Certainly one option is to not put them in the session, but you do have other 
options.  See last comment.

 without me getting warnings in the log file when I don't mark them as 
 serializable.

They *must* be serializable.  Otherwise you're going to get an exception.  This 
is a requirement of Java serialization.

 
 IS THERE A WAY TO STOP WARNINGS AND TELL TOMCAT NOT TO SERIALIZE A BEAN?
 
 Right now, I have stopped warnings but caused other problems.

As I've mentioned, your beans must implement Serializable or they won't be able 
to be serialized and you'll see error.  This is not an issue with Tomcat.  It's 
a requirement of Java serialization.  Tomcat uses Java serialization to persist 
your session data between restarts so it inherits this requirement.  

I would suggest that you look into how Java serializes your objects.  If you 
don't like the default behavior, it provides you with the ability to control 
that process.  One example, if you want to prohibit a field from being 
serialized you can mark it transient.

Dan

 
 
 
 
 
 On Monday, January 13, 2014 8:08 AM, Daniel Mikusa dmik...@gopivotal.com 
 wrote:
 
 On Jan 12, 2014, at 8:45 AM, Ray Holme rayho...@yahoo.com wrote:
 
 I haven't been following this thread, but I wanted to clarify a couple 
 comments here just to make sure someone reading this in the future doesn't 
 get the wrong ideas.
 
 serialization causes some problems in apache-tomcat-7.0.35
 
 No.  What causes problems is when application objects are placed in the 
 session and they are not serializable.  This happens because, by default, 
 Tomcat will try to save your session data when it restarts.  It does this by 
 serializing the data to disk.  Then when it restarts, it deserializes the 
 data and restores the sessions.
 
  
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts
 
 The only other reason why your sessions would need to be serializable is if 
 you're using clustering (i.e. you add the distributable tag to web.xml).
 
 I have several applications and run on fedora linux. I have used many 
 releases of fedora and tomcat.
 
 My applications are characterized by
     a) all use a DB (firebird)
     b) all use both jsp and java servlets
     c) all use transient java beans for a round of interaction (user 
request - user response)
     d) all have 1 or more session java beans for each user (login - logout)
     e) all have 1 or more application beans (initialized at startup, can 
refresh, passed around)
     f) all have an application specific jar and share a common code jar
 
 Long ago I added serialization to almost all of the java beans to stop 
 tomcat whining in the catalina.out file. This worked just fine until the 
 most recent tomcat release.
 
 On my development machine, java changes build new jars and apache/tomcat 
 must be restarted to work right. Starting with the new release, problems 
 with connections happened.
 
 After research, I discovered that the applications were going nuts with 
 connection requests and xinetd was 

META-INF/Context.xml path question

2014-01-13 Thread Bob DeRemer
We're trying to determine if it's possible to build a WAR with an embedded 
META-INF/Context.xml that defines the webapp path to be different then the WAR 
file name.   Let's say we have AppServer-version.war, but we want to access 
it as: http://host/Server.   In addition, we want to support 
uploading/installing the WAR both from the Manager app as well as using 
ftp/command-line to copy the WAR and restart Tomcat.  This way, it's pretty 
much automatic without editing/creating additional XML files.

If this works, then we can have identifiable WAR files, but with a 
common/standard webapp path.

We have reviewed the docs and the only approach that has worked for us is 
adding a separate Context element to the Tomcat/conf/Server.xml file.

Thanks,

_
ThingWorx, a PTC owned company

Bob DeRemer, Sr. Director Architecture/Development
bob.dere...@thingworx.commailto:bob.dere...@thingworx.com | 
www.thingworx.comhttp://www.thingworx.com/ | www.ptc.comhttp://www.ptc.com/
M: 717.881.3986 | O: 610.594.6200 x 812



Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Asok Chattopadhyay
Hi,
Sorry about that.
Here are the locations of the two files:

(1) http://workshop.dreamapps.com/da/docs/Test.java
(2) http://workshop.dreamapps.com/da/docs/test.html

Thanks.


On Tue, Jan 14, 2014 at 12:39 AM, Konstantin Preißer
kpreis...@apache.orgwrote:

 Hi,

  -Original Message-
  From: Asok Chattopadhyay [mailto:da.a...@gmail.com]
  Sent: Monday, January 13, 2014 4:52 PM
  To: Tomcat Users List
  Subject: Re: Tomcat strips CRLFs from the generated page
 
   I am attaching the Test servlet and the text file that contains the
  page.
   The Test servlet simply reads the file and sends out to the browser.
 When I
   run this servlet, it strips all CRLFs from line 153 onward.
  
   Thanks.

 The list strips most attachments. Please upload the files somewhere else
 and post a link to download them.


 Regards,
 Konstantin Preißer


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Asok Chattopadhyay
Andre: I changed the out.println(s) to out.print(s), but that did not make
any difference. Regards.


On Tue, Jan 14, 2014 at 1:40 AM, Asok Chattopadhyay da.a...@gmail.comwrote:

 Hi,
 Sorry about that.
 Here are the locations of the two files:

 (1) http://workshop.dreamapps.com/da/docs/Test.java
 (2) http://workshop.dreamapps.com/da/docs/test.html

 Thanks.


 On Tue, Jan 14, 2014 at 12:39 AM, Konstantin Preißer kpreis...@apache.org
  wrote:

 Hi,

  -Original Message-
  From: Asok Chattopadhyay [mailto:da.a...@gmail.com]
  Sent: Monday, January 13, 2014 4:52 PM
  To: Tomcat Users List
  Subject: Re: Tomcat strips CRLFs from the generated page
 
   I am attaching the Test servlet and the text file that contains the
  page.
   The Test servlet simply reads the file and sends out to the browser.
 When I
   run this servlet, it strips all CRLFs from line 153 onward.
  
   Thanks.

 The list strips most attachments. Please upload the files somewhere else
 and post a link to download them.


 Regards,
 Konstantin Preißer


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org





Re: Packet misses in Tomcat

2014-01-13 Thread Stefan Mayr

Am 13.01.2014 07:22, schrieb Divyaprakash Y:

-Original Message-
From: Stefan Mayr [mailto:ste...@mayr-stefan.de]
Sent: 10 January 2014 23:26
To: users@tomcat.apache.org
Subject: Re: Packet misses in Tomcat

Hi

Am 09.01.2014 14:21, schrieb Divyaprakash Y:



-Original Message-
From: Divyaprakash Y
Sent: 08 January 2014 14:35
To: Tomcat Users List
Subject: RE: Packet misses in Tomcat


...

Strange that this is happening only to me.

Looks like something similar was reported on the dev list when voting for 
Tomcat 7.0.50 ..

Thanks.




I tried same setup today with the BIO connector, everything worked flawlessly. 
Will there be any issue with the APR connector(earlier setup) or are there any 
extra configurations which I missed in my server.xml?


This might be the issue seen in
https://issues.apache.org/bugzilla/show_bug.cgi?id=55976 . Looks like Mark 
fixed it today for 7.0.51 (not released yet)

- Stefan





Thanks Stefan for the information.

Should that(Fix on NIO Connector) fix the possible issue in APR Connector as 
well?


I guess not. But maybe you shoudl 7.0.50 give a try. APR was updated in 
one of the not released versions after your lastest 7.0.42.
Also a minimal testcase would help to check if this is reproducable on 
other peoples machine (like they did in the bugzilla ticket)


- Stefan

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Konstantin Kolinko
2014/1/13 Asok Chattopadhyay da.a...@gmail.com:
 You can see the test servlet working at
 http://workshop.dreamapps.com/da/test


1. Downloading the page with WGET tool, all CRLFs (on line 153 and below) are OK

2. Opening the page in Firefox, and doing View page source shows
HTML markup errors (it highlights them in red).

E.g. line 319 has

a href=javascript:void(0);
onClick=document.forms.one.listcommand.value='open.alpha
#';submitCommand('dummy','one');None/a

Note that the double-quote symbol just before 'None' is doubled,
breaking the attribute markup.

You may want to try to pass your page through
http://validator.w3.org/


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread André Warnier

Asok Chattopadhyay wrote:

You can see the test servlet working at
http://workshop.dreamapps.com/da/test



According to what I see when I save this page and view it with an editor that can show the 
end-of-lines used, you have a terrible mixture of lines terminated by CR/LF, and lines 
terminated by LF alone. And this starts long before line 153 :


lines 1-6 : terminated by CR/LF
lines 7-46 : terminated by LF
lines 47-64 : CR/LF
etc..

I think that you should fix that first, before attempting to find anything that would 
strip characters unexpectedly, which is probably not happening.


It looks like you have cut and pasted together parts of different files of different 
origins, without paying attention to the different end-of-line sequences used.

Re-read my first answer.



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread André Warnier

Asok Chattopadhyay wrote:

Hi,
Sorry about that.
Here are the locations of the two files:

(1) http://workshop.dreamapps.com/da/docs/Test.java
(2) http://workshop.dreamapps.com/da/docs/test.html



Same comment as before, for the file test.html : the file itself contains a mixture of 
end-of-line sequences.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: META-INF/Context.xml path question

2014-01-13 Thread Caldarale, Charles R
 From: Bob DeRemer [mailto:bob.dere...@thingworx.com] 
 Subject: META-INF/Context.xml path question

 We're trying to determine if it's possible to build a WAR with an embedded 
 META-INF/Context.xml that defines the webapp path to be different then the 
 WAR file name.

Short answer: no.

 Let's say we have AppServer-version.war, but we want to access it as: 
 http://host/Server.

Just rename the .war file to Server.war as part of the deployment.  No muss, no 
fuss.

 We have reviewed the docs and the only approach that has worked for us is 
 adding a separate Context element to the Tomcat/conf/Server.xml file.

Along with the statement that putting Context elements in server.xml (not 
Server.xml) is strongly discouraged - don't do that.  You can keep the .war 
file outside of any Host appBase, and create an appName.xml file in 
conf/Catalina/[host] with a path attribute inside the Context element that 
points to the .war file.

 - 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



RE: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Konstantin Preißer
Hi,

 -Original Message-
 From: Asok Chattopadhyay [mailto:da.a...@gmail.com]
 Sent: Monday, January 13, 2014 6:41 PM
 To: Tomcat Users List
 Subject: Re: Tomcat strips CRLFs from the generated page
 
 Hi,
 Sorry about that.
 Here are the locations of the two files:
 
 (1) http://workshop.dreamapps.com/da/docs/Test.java
 (2) http://workshop.dreamapps.com/da/docs/test.html
 
 Thanks.

I just tried your Servlet and .html locally (in Tomcat 7.0.50 on Windows, but I 
think the behavior should be the same as in TC 6), and I tried your URL 
http://workshop.dreamapps.com/da/test, but in none of them I could find any 
stripped CR LFs.

If watch the source code of that URL, then e.g. Line 373 contains 
/body/html after a line break (CR LF), so the line breaks seem to work.


Some other points (which don't have to do with line breaks):

1) As Konstantin Kolinko noted, your .html page contains a lot of syntax errors.

2) Your .html page seems to be encoded in UTF-8, but your servlet uses the 
default encoding to decode the bytes to a String. One some platforms the 
default encoding is UTF-8, but on some like Windows it depends on the user's 
locale - one should explicitely set the used encoding. (Why are you using a 
DataInputStream to read a .html page? A InputStream should suffice for this.)

3) I wonder why you have this line in your servlet:

res.setHeader(X-UA-Compatible, IE=EmulateIE7)

This instructs IE to behave like the outdated IE 7 which does not implement a 
lot of current HTML functionality, but on the other hand you use a HTML5 
doctype (!DOCTYPE html) which seems to indicate that you intent to use the 
current HTML 5 features.

4) In Java 6 or earlier, it is a good practice to use try-catch-finally with 
resources like PrintWriter; Java 7 has try-with-resources syntax.

Regards,
Konstantin Preißer


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: META-INF/Context.xml path question

2014-01-13 Thread Mark Thomas
On 13/01/2014 17:38, Bob DeRemer wrote:
 We're trying to determine if it's possible to build a WAR with an
 embedded META-INF/Context.xml

It is context.xml, not Context.xml. Case matters.

 that defines the webapp path to be
 different then the WAR file name.

No, it is not possible to do this.

   Let's say we have
 AppServer-version.war, but we want to access it as:
 http://host/Server.   In addition, we want to support
 uploading/installing the WAR both from the Manager app as well as
 using ftp/command-line to copy the WAR and restart Tomcat.  This way,
 it's pretty much automatic without editing/creating additional XML
 files.
 
 If this works, then we can have identifiable WAR files, but with a
 common/standard webapp path.

The way to have identifiable WARs is to use the version element of the
filename. For example, server##1.0.15.war will be auto-deployed with a
context path of /server. The version tag can be pretty much anything you
like as long as the file name is valid. You don't have to be using
parallel deployment to make use of it.

 We have reviewed the docs and the only approach that has worked for
 us is adding a separate Context element to the
 Tomcat/conf/Server.xml file.

It is server.xml. Again, case matters.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: META-INF/Context.xml path question

2014-01-13 Thread Konstantin Kolinko
2014/1/13 Bob DeRemer bob.dere...@thingworx.com:

Tomcat version =?

 We're trying to determine if it's possible to build a WAR with an embedded 
 META-INF/Context.xml that defines the webapp path to be different then the 
 WAR file name.

Not possible.

BTW, the file name is context.xml (case sensitively).

  Let's say we have AppServer-version.war, but we want to access it as: 
 http://host/Server.

Rename your war file to  ROOT.war or  ROOT##AppServer-version.war.

The latter naming works on Tomcat 7 and 8 only.

  In addition, we want to support uploading/installing the WAR both from the 
 Manager app as well as using ftp/command-line to copy the WAR and restart 
 Tomcat.  This way, it's pretty much automatic without editing/creating 
 additional XML files.

 If this works, then we can have identifiable WAR files, but with a 
 common/standard webapp path.

 We have reviewed the docs and the only approach that has worked for us is 
 adding a separate Context element to the Tomcat/conf/Server.xml file.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Oracle Application Server 10g R3 works fine with RK-1048 codepage but Tomcat 7.0.47 does not.

2014-01-13 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Тимур,

On 1/13/14, 11:34 AM, Тимур Кулибаев wrote:
 Dears, I have checked documentation/FAQ/WEB/archives but it didn't
 help to resolve the following trouble: I have a java servlet which
 is currently deployed on Oracle Application Server 10g R3 with jdk
 1.5u19 on RHEl 5.7 and one works fine with Oracle Application
 Server. The servlet works with Oracle Database which has cyrillic
 single-byte codepage CL8MSWIN1251. The servlet was migrated from
 Oracle Application Server 10g R3 to Tomcat 7.0.47. I use Tomcat
 7.0.47 with jdk-1.6u38 on RHEl 5.7. The servlet works fine with
 Tomcat 7 except only trouble with some characters displaiyng.
 
 The point is that there is a special language driver for Windows
 which provides Kazakh extension for codepage Windows-1251. The
 language driver works in single-byte codepage named RK-1048 which
 is almost the same as widely known Windows-1251 codepage. Only
 difference between Windows-1251 and RK-1048 is that RK-1048 has 
 several specific Kazakh letters added (Kazakh alphabet equals
 Russian alphabet plus several specific letters of Kazakh
 language).
 
 The trouble is that specific Kazakh letters are not displaying
 correctly in servlet on Tomcat 7 but on Oracle Application Server
 all specific Kazakh letters are displayed correctly. Servlet
 operates by GET-requests when send data to server. So in my
 understanding I must get Tomcat worked in Windows-1251 for 
 GET-requests. Also, UTF-8 is not suit for me as database is in
 single-byte codepage.
 From Tomcat 7 documentation:
 There are two ways to specify how GET parameters are
 interpreted: 1.Set the URIEncoding attribute on the Connector
 element in server.xml to something specific (e.g.
 URIEncoding=UTF-8). 2.Set the useBodyEncodingForURI attribute on
 the Connector element in server.xml to true. This will cause the
 Connector to use the request body's encoding for GET parameters.
 
 I have tried URIEncoding and useBodyEncodingForURI on
 http-connector but it doesn't help.
 
 Connector port=7785 protocol=HTTP/1.1 
 connectionTimeout=2 redirectPort=8443 
 URIEncoding=Windows-1251 /
 
 or
 
 Connector port=7785 protocol=HTTP/1.1 
 connectionTimeout=2 redirectPort=8443 
 useBodyEncodingForURI=true /
 
 or Connector port=7785 protocol=HTTP/1.1 
 connectionTimeout=2 redirectPort=8443 
 URIEncoding=Windows-1251 useBodyEncodingForURI=true /
 
 Why Oracle Application Server works fine with RK-1048 codepage but
 Tomcat 7.0.47 does not ?

What are the user.language and user.country system properties for
your running Tomcat instance?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJS1FSkAAoJEBzwKT+lPKRYv2sQALV3fEs9cBdPLE3RTEcapCOH
dAkaeuKK9MS60RAemVwP6okqzD0ect/dwVQA1Pi6yMzKTKXPdDWwif1rhlxOjAjY
YvzwBhRGKdaM7C4vPLoasBRC6bVUDPS9Ct0JAVnBbBOS8qKXc38BcBb+yXwjyGml
OlGzUzN8d/1VVjAU6WlIHx1AAcXj0eL7fD7m6B10w3bYx5kPdN/CY0rV2Scv5VnZ
aFrv9kkLQjEsaG5/rljt7ff/UprLRupOunsBGV6RwKQ/o+UMrlDevm91F+QOW+oM
DkCXNKLbwSXzyVgRyAnY9RsGAN11m8F/wRZxkdvDQUMdztBSm4dvGr0e1rflN4Lc
Bh84UtzYihwLkcT3vtNPnTnqCprdF6Bvddu19DpjYiZiyiVPBi6/DA4WQAWuHASh
VogL+PZYYEoZjID6azZtSPJN7ufLxbrvwrsB8L837wv7+bF+t/v8vbVbvjUsFKzP
TwcyNyk6kVRdXiCPu6PSZPYeKhfPRK6s28kCY5O5KF9gJxF++LMVHQ7t5sbBCpC4
RIki+aIbz0nEtNYfcV9xyHgkOI/nx4T0QIVVhH0b7nvaUKiu4QVeYKcXR4Q4Qj/3
3VuhSETxkfzlVmowzQaZvlMSLNB0cpzmq4QQwdOCG83D2gfZhEcMxCDgI/cxPZmh
USKdg3dMF23ph0J1QM9W
=9YsA
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Mark Eggers

On 1/13/2014 9:40 AM, Asok Chattopadhyay wrote:

Hi,
Sorry about that.
Here are the locations of the two files:

(1) http://workshop.dreamapps.com/da/docs/Test.java
(2) http://workshop.dreamapps.com/da/docs/test.html

Thanks.


On Tue, Jan 14, 2014 at 12:39 AM, Konstantin Preißer
kpreis...@apache.orgwrote:


Hi,


-Original Message-
From: Asok Chattopadhyay [mailto:da.a...@gmail.com]
Sent: Monday, January 13, 2014 4:52 PM
To: Tomcat Users List
Subject: Re: Tomcat strips CRLFs from the generated page


I am attaching the Test servlet and the text file that contains the

  page.

The Test servlet simply reads the file and sends out to the browser.

When I

run this servlet, it strips all CRLFs from line 153 onward.

Thanks.


The list strips most attachments. Please upload the files somewhere else
and post a link to download them.


Regards,
Konstantin Preißer


Dropping the HTML into Firefox / HTMLTidy I get 751 errors and 167 warnings.

Some of these could be due to a cascading error effect . . .

However, first things first: clean up your HTML.

1. validate it
2. fix CR/LF
3. fix javascript (terminate lines with ';')

I suggest you throw the code into an IDE and start working with the 
suggestions given therein.


Mark
/mde/


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: Would a developer please add this mime type to the distro?

2014-01-13 Thread Jeffrey Janner
 -Original Message-
 From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
 Sent: Friday, January 10, 2014 9:04 PM
 To: Tomcat Users List
 Subject: Re: Would a developer please add this mime type to the distro?
 
 2014/1/11 Jeffrey Janner jeffrey.jan...@polydyne.com:
  Tomcat 7 did a good job of collecting all the new Microsoft mime
 types into the standard web.xml file, but missed the mapping for the
 .one file type for OneNote, even though that's fully documented on
 the Microsoft Mime Types page.
 
 1. What page, exactly?
 

The one on Microsoft's TechNet:
http://technet.microsoft.com/en-us/library/ee309278(v=office.12).aspx

My guess is whomever transcribed this list into HTTPD, accidently skipped this 
one entry.
This is the page I built the entries in my web.xml from years ago.

The entry is:
 
mime-mapping
  extensionone/extension
  mime-typeapplication/onenote/mime-type
/mime-mapping
 
  I know I can always add it to my local web.xml, but it's now the only
 one I need and I figured that others might like to have it available as
 a default as well.
 
 2. The list of mime types in Tomcat is kept in sync with the similar
 list in Apache HTTPD.
 
 If I look at HTTPD trunk, that mime-type is mapped to extensions
 onetoc onetoc2 onetmp onepkg.
 
 http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/conf/mime.types?vie
 w=markup#l159
 
 3. IMHO application/onenote is not a valid mime type on the Internet,
 as it is not registered with IANA.
 
 http://www.iana.org/assignments/media-types/media-
 types.xhtml#application
 

What?  You expect Microsoft to do things the generally accepted and/or correct 
way?

 4. Formally, a way to go is to file an enhancement request.
 
And I do that how?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



tomcat gracefull shutdown problem

2014-01-13 Thread Ja kub
I modified conf/context.xml Context unloadDelay=6
I hoped tomcat would wait 60 seconds for request to end.
But there are some problems with spring app, I get

HTTP Status 503 - Servlet jsp is currently unavailable:

I use tomcat 7.42 64 bit on windows 7

steps to reproduce:

use app from https://github.com/spring-projects/spring-petclinic

git clone https://github.com/SpringSource/spring-petclinic.git

to VetController class add:

@RequestMapping(/vets/{delay})
public String showVetListDelayed(@PathVariable int delay, MapString,
Object model) {
// Here we are returning an object of type 'Vets' rather than a
collection of Vet objects
// so it is simpler for Object-Xml mapping
Vets vets = new Vets();
vets.getVetList().addAll(this.clinicService.findVets());
model.put(vets, vets);
try {
Thread.sleep(1000*delay);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
}
System.err.println(woken up ---);
return vets/vetList;
}

mvn clean install

// copy from target to webapps

go to
http://localhost:8080/petclinic/vets/5
hit ctrl C

app sleeps,  wait until
System.err.println(woken up ---); executes 
but browser gets error.

below is console log:

Hibernate: select distinct vet0_.id as id1_5_0_, specialty2_.id as
id1_2_1_, vet0_.first_
 specialty2_.name as name2_2_1_, specialtie1_.vet_id as vet1_5_0__,
specialtie1_.specialt
join vet_specialties specialtie1_ on vet0_.id=specialtie1_.vet_id left
outer join special
alty2_.id order by vet0_.last_name, vet0_.first_name
Jan 14, 2014 1:20:15 AM org.apache.catalina.core.StandardServer await
INFO: A valid shutdown command was received via the shutdown port. Stopping
the Server in
Jan 14, 2014 1:20:15 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler [http-apr-8080]
Jan 14, 2014 1:20:15 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler [ajp-apr-8009]
Jan 14, 2014 1:20:15 AM org.apache.catalina.core.StandardService
stopInternal
INFO: Stopping service Catalina
Jan 14, 2014 1:20:16 AM org.apache.catalina.core.StandardWrapper unload
INFO: Waiting for 1 instance(s) to be deallocated for Servlet [petclinic]
woken up ---
INFO  XmlWebApplicationContext - Closing WebApplicationContext for
namespace 'petclinic-s
]; parent: Root WebApplicationContext
INFO  XmlWebApplicationContext - Closing Root WebApplicationContext:
startup date [Tue Ja
INFO  AnnotationMBeanExporter - Unregistering JMX-exposed beans on shutdown
INFO  EhCacheManagerFactoryBean - Shutting down EhCache CacheManager
INFO  LocalContainerEntityManagerFactoryBean - Closing JPA
EntityManagerFactory for persi
Jan 14, 2014 1:20:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc
SEVERE: The web application [/petclinic] registered the JDBC driver
[org.hsqldb.jdbc.JDBC
plication was stopped. To prevent a memory leak, the JDBC Driver has been
forcibly unregi
Jan 14, 2014 1:20:22 AM org.apache.catalina.loader.WebappClassLoader
clearReferencesThrea
SEVERE: The web application [/petclinic] appears to have started a thread
named [PoolClea
p it. This is very likely to create a memory leak.
Jan 14, 2014 1:20:22 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler [http-apr-8080]
Jan 14, 2014 1:20:22 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler [ajp-apr-8009]
Jan 14, 2014 1:20:22 AM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler [http-apr-8080]
Jan 14, 2014 1:20:22 AM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler [ajp-apr-8009]


Regards
Jakub


Re: Tomcat strips CRLFs from the generated page

2014-01-13 Thread Asok Chattopadhyay
As I said before, I have no control over the input text. In the test
servlet I am simply reading text from a file and sending it out to the
browser. No other processing has been done to the text by the servlet. The
browser, however, receives a page with CRLF stripped starting from a
certain point in the text.
If I View source in the browser, I can see that happening.

This is consistent over most operating systems (Windows and Linux) and most
browsers (IE, Firefox and Chrome) and the stripping happens exactly at the
same point onward, in all combinations of OS and browser.

My question is: who is stripping the CRLF from the text? Is it Tomcat or
the browser? Is Tomcat doing any validation of the text before sending it
out to the client?


Thanks and regards.


On Tue, Jan 14, 2014 at 5:16 AM, Mark Eggers its_toas...@yahoo.com wrote:

 On 1/13/2014 9:40 AM, Asok Chattopadhyay wrote:

 Hi,
 Sorry about that.
 Here are the locations of the two files:

 (1) http://workshop.dreamapps.com/da/docs/Test.java
 (2) http://workshop.dreamapps.com/da/docs/test.html

 Thanks.


 On Tue, Jan 14, 2014 at 12:39 AM, Konstantin Preißer
 kpreis...@apache.orgwrote:

  Hi,

  -Original Message-
 From: Asok Chattopadhyay [mailto:da.a...@gmail.com]
 Sent: Monday, January 13, 2014 4:52 PM
 To: Tomcat Users List
 Subject: Re: Tomcat strips CRLFs from the generated page

  I am attaching the Test servlet and the text file that contains the

   page.

 The Test servlet simply reads the file and sends out to the browser.

 When I

 run this servlet, it strips all CRLFs from line 153 onward.

 Thanks.


 The list strips most attachments. Please upload the files somewhere else
 and post a link to download them.


 Regards,
 Konstantin Preißer


 Dropping the HTML into Firefox / HTMLTidy I get 751 errors and 167
 warnings.

 Some of these could be due to a cascading error effect . . .

 However, first things first: clean up your HTML.

 1. validate it
 2. fix CR/LF
 3. fix javascript (terminate lines with ';')

 I suggest you throw the code into an IDE and start working with the
 suggestions given therein.

 Mark
 /mde/



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




Re: Oracle Application Server 10g R3 works fine with RK-1048 codepage but Tomcat 7.0.47 does not.

2014-01-13 Thread Тимур Кулибаев
Hello, Christopher !

The user.language and user.country system properties for my running
Tomcat instance are not set.
In Oracle Apllication Server I also do not see these properties set in ps
-ef | grep java output.
I set both properties in JAVA_OPTS env.var:

[oracle@n36 logs]$ echo $JAVA_OPTS
-XX:MaxPermSize=128M -Xms256m -Xmx1024m -Duser.language=ru -Duser.country=RU

Check whether java process has these settings:
[oracle@n36 logs]$ ps -ef | grep java
oracle   17311 1 18 13:31 pts/000:00:41
/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/jdk-6u38-linux/jdk1.6.0_38/bin/java
-Djava.util.logging.config.file=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-XX:MaxPermSize=128M -Xms256m -Xmx1024m -Duser.language=ru
-Duser.country=RU
-Djava.endorsed.dirs=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/endorsed
-classpath
/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/bin/bootstrap.jar:/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/bin/tomcat-juli.jar
-Dcatalina.base=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47
-Dcatalina.home=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47
-Djava.io.tmpdir=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/temp
org.apache.catalina.startup.Bootstrap start
oracle   17369 17164  0 13:35 pts/000:00:00 grep java

After setting user.language and user.country I tested servlet on Tomcat
7 again but it didn't help, trouble persists.
What else are to be fixed in Tomcat conf ?

thank you, Timur

PS: I'm in Kazakhstan, at GMT+6, so sorry for delay with answer.



2014/1/14 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Тимур,

 On 1/13/14, 11:34 AM, Тимур Кулибаев wrote:
  Dears, I have checked documentation/FAQ/WEB/archives but it didn't
  help to resolve the following trouble: I have a java servlet which
  is currently deployed on Oracle Application Server 10g R3 with jdk
  1.5u19 on RHEl 5.7 and one works fine with Oracle Application
  Server. The servlet works with Oracle Database which has cyrillic
  single-byte codepage CL8MSWIN1251. The servlet was migrated from
  Oracle Application Server 10g R3 to Tomcat 7.0.47. I use Tomcat
  7.0.47 with jdk-1.6u38 on RHEl 5.7. The servlet works fine with
  Tomcat 7 except only trouble with some characters displaiyng.
 
  The point is that there is a special language driver for Windows
  which provides Kazakh extension for codepage Windows-1251. The
  language driver works in single-byte codepage named RK-1048 which
  is almost the same as widely known Windows-1251 codepage. Only
  difference between Windows-1251 and RK-1048 is that RK-1048 has
  several specific Kazakh letters added (Kazakh alphabet equals
  Russian alphabet plus several specific letters of Kazakh
  language).
 
  The trouble is that specific Kazakh letters are not displaying
  correctly in servlet on Tomcat 7 but on Oracle Application Server
  all specific Kazakh letters are displayed correctly. Servlet
  operates by GET-requests when send data to server. So in my
  understanding I must get Tomcat worked in Windows-1251 for
  GET-requests. Also, UTF-8 is not suit for me as database is in
  single-byte codepage.
  From Tomcat 7 documentation:
  There are two ways to specify how GET parameters are
  interpreted: 1.Set the URIEncoding attribute on the Connector
  element in server.xml to something specific (e.g.
  URIEncoding=UTF-8). 2.Set the useBodyEncodingForURI attribute on
  the Connector element in server.xml to true. This will cause the
  Connector to use the request body's encoding for GET parameters.
 
  I have tried URIEncoding and useBodyEncodingForURI on
  http-connector but it doesn't help.
 
  Connector port=7785 protocol=HTTP/1.1
  connectionTimeout=2 redirectPort=8443
  URIEncoding=Windows-1251 /
 
  or
 
  Connector port=7785 protocol=HTTP/1.1
  connectionTimeout=2 redirectPort=8443
  useBodyEncodingForURI=true /
 
  or Connector port=7785 protocol=HTTP/1.1
  connectionTimeout=2 redirectPort=8443
  URIEncoding=Windows-1251 useBodyEncodingForURI=true /
 
  Why Oracle Application Server works fine with RK-1048 codepage but
  Tomcat 7.0.47 does not ?

 What are the user.language and user.country system properties for
 your running Tomcat instance?

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQIcBAEBCAAGBQJS1FSkAAoJEBzwKT+lPKRYv2sQALV3fEs9cBdPLE3RTEcapCOH
 dAkaeuKK9MS60RAemVwP6okqzD0ect/dwVQA1Pi6yMzKTKXPdDWwif1rhlxOjAjY
 YvzwBhRGKdaM7C4vPLoasBRC6bVUDPS9Ct0JAVnBbBOS8qKXc38BcBb+yXwjyGml
 OlGzUzN8d/1VVjAU6WlIHx1AAcXj0eL7fD7m6B10w3bYx5kPdN/CY0rV2Scv5VnZ
 aFrv9kkLQjEsaG5/rljt7ff/UprLRupOunsBGV6RwKQ/o+UMrlDevm91F+QOW+oM