Re: ELB Creating Multiple Sessions with Every Ping

[Peter Rifel]

Yuval,



On 2/8/16, 6:57 AM, "Christopher Schultz"  wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Yuval,
>
>On 2/7/16 2:27 AM, Yuval Schwartz wrote:
>> tomcat version: 8.0.22 java: jdk1.8.0_05 server: amazon linux ami
>> 
>> This might be outside the scope of this forum. I have an ELB
>> (Elastic Load Balancer) distributing load between two instances
>> that run tomcat. When I observe the tomcat manager app I see that
>> at every health check interval (1 per 60 seconds) the ELB is
>> creating 4 new sessions (ie: 4 different session ids are listed in
>> the "Sessions Adminstration" page per ping). Is this normal? Why
>> doesn't it just create 1 session per ping?
>
>Because the ELB doesn't maintain JSESSIONID cookies across pings.

Also I've noticed in my Tomcat access logs that ELB health checks come from two 
different IP addresses and each performs a check at the defined interval, so 
you may see double the requests.

Peter




>
>What you need to do is pick a different URL for the ELB to use to ping
>the backend instances: one that won't automatically create a new session
>.
>
>- -chris
>-BEGIN PGP SIGNATURE-
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iEYEARECAAYFAla4rOQACgkQ9CaO5/Lv0PDnuwCdFqdNo6cZJO26fj0zvLFsr1Bw
>48EAoLhRkEwSpB76yDIvBcEMNi8H/oqU
>=2R3W
>-END PGP SIGNATURE-
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: Tomcat 8 Chunked Encoding

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Theo,

On 2/8/16 10:17 AM, Theo Sweeny wrote:
> Hello All - I'm running Tomcat 8.0.21 on Linux 64x and there is a
> recent issue where clients making requests and declaring the header
> - Transfer-Encoding:chunked, have their connections hang, with no
> obvious leads in the logs.
> 
> I'm aware that up to version 8.0.9 there was a Tomcat vulnerability
> with regards to this header type.
> 
> Could it be that there are legacy Tomcat security features that are
> causing the request to hang?

Is it possible for you to test with 8.0.latest? 8.0.32 was just voted
stable.

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

iEYEARECAAYFAla4wUAACgkQ9CaO5/Lv0PBf4wCgpw/ZIXZFr6rn1LYmy7xK6lVj
Vz8AnRCANSoSzLEZEQ/9BgGWhxhJxRTd
=Jfv7
-END PGP SIGNATURE-

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

Re: ELB Creating Multiple Sessions with Every Ping

[Yuval Schwartz]

On Mon, Feb 8, 2016 at 6:53 PM, Peter Rifel  wrote:

> Yuval,
>
>
>
> On 2/8/16, 6:57 AM, "Christopher Schultz" 
> wrote:
>
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >Yuval,
> >
> >On 2/7/16 2:27 AM, Yuval Schwartz wrote:
> >> tomcat version: 8.0.22 java: jdk1.8.0_05 server: amazon linux ami
> >>
> >> This might be outside the scope of this forum. I have an ELB
> >> (Elastic Load Balancer) distributing load between two instances
> >> that run tomcat. When I observe the tomcat manager app I see that
> >> at every health check interval (1 per 60 seconds) the ELB is
> >> creating 4 new sessions (ie: 4 different session ids are listed in
> >> the "Sessions Adminstration" page per ping). Is this normal? Why
> >> doesn't it just create 1 session per ping?
> >
> >Because the ELB doesn't maintain JSESSIONID cookies across pings.
>
> Also I've noticed in my Tomcat access logs that ELB health checks come
> from two different IP addresses and each performs a check at the defined
> interval, so you may see double the requests.
>
>
Yes, thank you. I read somewhere that ELB's ping from each instance running
the ELB (which is determined by load on the ELB), so it could fluctuate.
I'll look into this as well as Christopher's answer.


> Peter
>
>
>
>
> >
> >What you need to do is pick a different URL for the ELB to use to ping
> >the backend instances: one that won't automatically create a new session
> >.
> >
> >- -chris
> >-BEGIN PGP SIGNATURE-
> >Comment: GPGTools - http://gpgtools.org
> >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >iEYEARECAAYFAla4rOQACgkQ9CaO5/Lv0PDnuwCdFqdNo6cZJO26fj0zvLFsr1Bw
> >48EAoLhRkEwSpB76yDIvBcEMNi8H/oqU
> >=2R3W
> >-END PGP SIGNATURE-
> >
> >-
> >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>

[ANN] Apache Tomcat 9.0.0.M3 available

[Mark Thomas]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 9.0.0.M3.

Apache Tomcat 9 is an open source software implementation of the Java
Servlet, JavaServer Pages, Java Unified Expression Language and Java
WebSocket technologies.

Apache Tomcat 9.0.0.M3 is a milestone release of the 9.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 9.0.x so that they may provide feedback. The notable
changes compared to 9.0.0.M1 include:

- Added the ability to use OpenSSL with JSSE style TLS configuration

- Added support for relative HTTP redirects

- Added the ability to access the CredentialHandler via the
  ServletContext

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-90.cgi

Migration guides from Apache Tomcat 5.5.x, 6.0.x, 7.0.x and 8.0.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

Re: Fwd: NoClassDefFoundError during graceful shutdown

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hrishikesh,

On 2/8/16 9:50 AM, Christopher Schultz wrote:
> Hrishikesh,
> 
> On 2/6/16 1:17 PM, Hrishikesh Gadre wrote:
>> Thanks for the reply. Let me try this out. But do you think its a
>> bug in Tomcat ?
> 
> No. There's nothing Tomcat can do about this, aside from allowing 
> your application to load /more/ classes on shutdown. What's 
> happening is that your application (or one of its libraries) is 
> being very sloppy.
> 
>> Because as an application developer I should be able to invoke 
>> arbitrary application logic during the 
>> ServletFilter::destroy(...) method without bothering about the 
>> class loading related issues (Note that the jar files for these 
>> classes are available inside WEB-INF/lib directory and the 
>> shutdown process completes successfully most of the times
>> without raising NoClassDefFoundErrors).
> 
> I just read the SO reference you posted and, in that case (if the 
> answer by "miljanm" is accurate), the library isn't properly using 
> its own ClassLoader if it's using a private one.
> 
> It's not clear to me which ClassLoader is failing to find 
> c.g.c.c.RemovalCause. Usually, the WebappClassLoader will issue a 
> WARN or INFO message to the log saying that a class is being
> loaded during shutdown. Do you see any such messages in any of the
> log files? If not, this may be *entirely* a library issue.

Also, see this SO issue for an example of what Tomcat usually says:
http://stackoverflow.com/questions/9920974/what-is-the-proper-way-to-shu
tdown-threads-when-tomcat-closes?rq=1

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

iEYEARECAAYFAla4q8oACgkQ9CaO5/Lv0PCz1wCglWVQGY4lpdIMWGGmX0byCA6a
vuwAni8c+i6U0AYoUUftoTX79a2CDyzr
=goJV
-END PGP SIGNATURE-

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

Re: Fwd: NoClassDefFoundError during graceful shutdown

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hrishikesh,

On 2/8/16 9:50 AM, Christopher Schultz wrote:
> Hrishikesh,
> 
> On 2/6/16 1:17 PM, Hrishikesh Gadre wrote:
>> Thanks for the reply. Let me try this out. But do you think its
>> a bug in Tomcat ?
> 
> No. There's nothing Tomcat can do about this, aside from allowing
> your application to load /more/ classes on shutdown. What's
> happening is that your application (or one of its libraries) is
> being very sloppy.
> 
>> Because as an application developer I should be able to invoke 
>> arbitrary application logic during the
>> ServletFilter::destroy(...) method without bothering about the
>> class loading related issues (Note that the jar files for these
>> classes are available inside WEB-INF/lib directory and the
>> shutdown process completes successfully most of the times without
>> raising NoClassDefFoundErrors).
> 
> I just read the SO reference you posted and, in that case (if the 
> answer by "miljanm" is accurate), the library isn't properly using
> its own ClassLoader if it's using a private one.
> 
> It's not clear to me which ClassLoader is failing to find 
> c.g.c.c.RemovalCause. Usually, the WebappClassLoader will issue a
> WARN or INFO message to the log saying that a class is being loaded
> during shutdown. Do you see any such messages in any of the log
> files? If not, this may be *entirely* a library issue.

Also, see this SO issue for an example of what Tomcat usually says:
http://stackoverflow.com/questions/9920974/what-is-the-proper-way-to-shu
tdown-threads-when-tomcat-closes?rq=1

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

iEYEARECAAYFAla4q8MACgkQ9CaO5/Lv0PDf+gCgj4iCSYFwKph6tpDkB5GzNYOu
8L8AnjuTH/f6frohS7gtEALSO4lKxQ6g
=zOP2
-END PGP SIGNATURE-

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

Re: Fwd: NoClassDefFoundError during graceful shutdown

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hrishikesh,

On 2/6/16 1:17 PM, Hrishikesh Gadre wrote:
> Thanks for the reply. Let me try this out. But do you think its a
> bug in Tomcat ?

No. There's nothing Tomcat can do about this, aside from allowing your
application to load /more/ classes on shutdown. What's happening is
that your application (or one of its libraries) is being very sloppy.

> Because as an application developer I should be able to invoke 
> arbitrary application logic during the ServletFilter::destroy(...)
> method without bothering about the class loading related issues
> (Note that the jar files for these classes are available inside
> WEB-INF/lib directory and the shutdown process completes
> successfully most of the times without raising 
> NoClassDefFoundErrors).

I just read the SO reference you posted and, in that case (if the
answer by "miljanm" is accurate), the library isn't properly using its
own ClassLoader if it's using a private one.

It's not clear to me which ClassLoader is failing to find
c.g.c.c.RemovalCause. Usually, the WebappClassLoader will issue a WARN
or INFO message to the log saying that a class is being loaded during
shutdown. Do you see any such messages in any of the log files? If
not, this may be *entirely* a library issue.

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

iEYEARECAAYFAla4qzYACgkQ9CaO5/Lv0PDHbACgwnjRtzoKp6MxS+mqkm9egQjm
hdoAniUTCkProbKW3K2BG3wtgaCJJeYi
=R5EV
-END PGP SIGNATURE-

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

HSTS missing from HTTPS server on tomcat 8.0.27

[dkumar]

Hi,

We are unable to fix the vulnerability of "HSTS missing from HTTPS server" 
on apache tomcat  8.0.27 while running on unix operating system. Below is 
the system configuration:

 OS Name:   HP-UX
 OS Version:B.11.31
 Architecture:   IA64N
Java Home:/opt/java8/jre
JVM Version:  1.8.0.04-hp-ux-b2
JVM Vendor:   Hewlett-Packard Company

We have uncommented the httpHeaderSecurity in the filter tag of 
conf/web.xml file, but still the vulnerability exists. We have also tried 
with apache tomcat 8.0.30, but in vain.


Any help to fix this vulnerability is appreciated.

Thanks & Regards
Deepak Kumar
"Disclaimer and confidentiality clause -
 This message and any attachments relating to official business of CCIL OR ANY 
OF IT'S SUBSIDIARIES is proprietary to CCIL and intended for the original 
addressee only.
The message may contain information that is confidential and subject to legal 
privilege. 
Any views expressed in this message are those of the individual sender. 
If you have received this message in error, please notify the original sender 
immediately and destroy the message and copies thereof and any attachments 
contained in it .
 If you are not the intended recipient of this message, you are hereby notified 
that you must not disseminate, copy, use, distribute, or take any action in 
connection therewith. 
 CCIL cannot ensure that the integrity of this communication has been 
maintained nor that it is free of errors, viruses, interception and/or 
interference. 
CCIL is not liable whatsoever for loss or damage resulting from the opening of 
this message and/or attachments and/or the use of the information contained in 
this message and/or attachments."

Re: 'javax.xml.parsers.FactoryConfigurationError: Provider for class javax.xml.parsers.DocumentBuilderFactory cannot be created' for Tomcat Valve

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chiranga,

On 2/7/16 2:27 AM, Chiranga Alwis wrote:
> I think OpenSAML seems to be using 
> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl. I am actually
> having this class within the lib folder of Tomcat.

Replacing XML parsers within applications is always a sticky business.
Have you tried simply removing your local Xerces implementation from
your web application to see if that works?

- -chris

> On Sun, Feb 7, 2016 at 12:41 PM, Chiranga Alwis
>  wrote:
> 
>> Hi Chris,
>> 
>> Yes I do. This is a SAML based single-sign-on valve for Tomcat.
>> 
>> On Sat, Feb 6, 2016 at 2:58 AM, Christopher Schultz < 
>> ch...@christopherschultz.net> wrote:
>> 
> Chiranga,
> 
> On 2/4/16 3:10 PM, Chiranga Alwis wrote:
> I have specified the following issue in stackoverflow: 
> http://stackoverflow.com/questions/35210472/javax-xml-parsers-fact
oryc
>
> 
onfigurationerror-provider-for-class-javax-xml-parse
> 
>
>  So
> 
> you have a serialized SAML object, and it's trying to parse XML as 
> it's being deserialized?
> 
> Are you (or is OpenSAML) using any kind of custom XML parser?
> 
> -chris
> 
>>> 
>>> 
- -
>>>
>>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
>>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAla4q48ACgkQ9CaO5/Lv0PDK8wCgsgGKJK0xwYrcDJPk4glV4pyg
Z7oAnR+nNPS0eyjQ6MYYiffDzsiAJdeL
=K9nv
-END PGP SIGNATURE-

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

Re: ELB Creating Multiple Sessions with Every Ping

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yuval,

On 2/7/16 2:27 AM, Yuval Schwartz wrote:
> tomcat version: 8.0.22 java: jdk1.8.0_05 server: amazon linux ami
> 
> This might be outside the scope of this forum. I have an ELB
> (Elastic Load Balancer) distributing load between two instances
> that run tomcat. When I observe the tomcat manager app I see that
> at every health check interval (1 per 60 seconds) the ELB is
> creating 4 new sessions (ie: 4 different session ids are listed in
> the "Sessions Adminstration" page per ping). Is this normal? Why
> doesn't it just create 1 session per ping?

Because the ELB doesn't maintain JSESSIONID cookies across pings.

What you need to do is pick a different URL for the ELB to use to ping
the backend instances: one that won't automatically create a new session
.

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

iEYEARECAAYFAla4rOQACgkQ9CaO5/Lv0PDnuwCdFqdNo6cZJO26fj0zvLFsr1Bw
48EAoLhRkEwSpB76yDIvBcEMNi8H/oqU
=2R3W
-END PGP SIGNATURE-

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

Tomcat 8 Chunked Encoding

[Theo Sweeny]

Hello All - I'm running Tomcat 8.0.21 on Linux 64x and there is a recent issue 
where clients making requests and declaring the header - 
Transfer-Encoding:chunked, have their connections hang, with no obvious leads 
in the logs.

I'm aware that up to version 8.0.9 there was a Tomcat vulnerability with 
regards to this header type.

Could it be that there are legacy Tomcat security features that are causing the 
request to hang?

Theo

Avios Group (AGL) Ltd is a limited company registered in England (registered 
number 2260073 and VAT number 512566754) whose registered address is Astral 
Towers, Betts Way, London Road, Crawley, West Sussex RH10 9XY . Avios Group 
(AGL) Limited is part of the IAG group of companies This email and any files 
transmitted with it are confidential and intended solely for the use of the 
individual or entity to whom they are addressed. If you have received this 
email in error please notify the system manager.

RE: HSTS missing from HTTPS server on tomcat 8.0.27

[Harrie Robins]

Hello!

Missing HSTS is not a vulnerability, as Mark pointed out, it is a feature.
In your web.xml

  
httpHeaderSecurity
 
org.apache.catalina.filters.HttpHeaderSecurityFilter

hstsEnabled
true


hstsMaxAgeSeconds
31536000


hstsIncludeSubDomains
true

true


This will NOT activate HSTS for your application, you will need to add this
mapping as well (edit to needs and add to application):


httpHeaderSecurity
/*
REQUEST


Regards,

Harrie

-Original Message-
From: dku...@ccilindia.co.in [mailto:dku...@ccilindia.co.in] 
Sent: maandag 8 februari 2016 15:50
To: 'Tomcat Users List' 
Subject: HSTS missing from HTTPS server on tomcat 8.0.27

Hi,

We are unable to fix the vulnerability of "HSTS missing from HTTPS server" 
on apache tomcat  8.0.27 while running on unix operating system. Below is
the system configuration:

 OS Name:   HP-UX
 OS Version:B.11.31
 Architecture:   IA64N
Java Home:/opt/java8/jre
JVM Version:  1.8.0.04-hp-ux-b2
JVM Vendor:   Hewlett-Packard Company

We have uncommented the httpHeaderSecurity in the filter tag of conf/web.xml
file, but still the vulnerability exists. We have also tried with apache
tomcat 8.0.30, but in vain.


Any help to fix this vulnerability is appreciated.

Thanks & Regards
Deepak Kumar
"Disclaimer and confidentiality clause -  This message and any attachments
relating to official business of CCIL OR ANY OF IT'S SUBSIDIARIES is
proprietary to CCIL and intended for the original addressee only.
The message may contain information that is confidential and subject to
legal privilege. 
Any views expressed in this message are those of the individual sender. 
If you have received this message in error, please notify the original
sender immediately and destroy the message and copies thereof and any
attachments contained in it .
 If you are not the intended recipient of this message, you are hereby
notified that you must not disseminate, copy, use, distribute, or take any
action in connection therewith. 
 CCIL cannot ensure that the integrity of this communication has been
maintained nor that it is free of errors, viruses, interception and/or
interference. 
CCIL is not liable whatsoever for loss or damage resulting from the opening
of this message and/or attachments and/or the use of the information
contained in this message and/or attachments."


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

Re: HSTS missing from HTTPS server on tomcat 8.0.27

[Mark Thomas]

On 08/02/2016 14:49, dku...@ccilindia.co.in wrote:
> Hi,
> 
> We are unable to fix the vulnerability of "HSTS missing from HTTPS server"

That is a not a security vulnerability. It is a configuration choice.

> on apache tomcat  8.0.27 while running on unix operating system. Below is 
> the system configuration:
> 
>  OS Name:   HP-UX
>  OS Version:B.11.31
>  Architecture:   IA64N
> Java Home:/opt/java8/jre
> JVM Version:  1.8.0.04-hp-ux-b2
> JVM Vendor:   Hewlett-Packard Company
> 
> We have uncommented the httpHeaderSecurity in the filter tag of 
> conf/web.xml file,

Exactly what have you uncommented? Did you remember to uncomment the
filter mapping as well as the filter definition?

Mark

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

Having Java websocket server in tomcat handle ISO8859_1

[Jason Ricles]

I have an application that sends binary websocket messages between a
class and the web application using a websocket server written in
java.

The data being sent from the java class is encoded in a binary buffer
with the bytes in ISO8859_1. However, when I receive the bytes on the
websocket server and the web application end they are junk (such as
-121, -116, etc.) and not encoded the correct way that they need to
be.

I was reading that this might be caused by something being set in my
websocket server and web application to use UTF-8 for the default and
not ISO8859_1.

Is there any way I can change my websocket server and my web
application which uses JavaScript to use ISO8859_1 instead of UTF-8?

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

RE: Relative redirects in light of recent changes

[George Stanchev]

In Tomcat 7.0.67 with no "useRelativeRedirects" set on the context (which 
defaults it to "true"), I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "login?a=b=d"

Now, this is expected behavior given the fix for [1]

[1] http://bz.apache.org/bugzilla/show_bug.cgi?id=56917


I reread my email, and it is incorrect that is expected behavior. I guess an 
expected behavior would be 

GET http://hostname/myapp?m=n=p 
  ==> 302: "myapp/login?a=b=d"

unless I am missing something badly...

George

Re: Having Java websocket server in tomcat handle ISO8859_1

[Mark Thomas]

On 08/02/2016 18:41, Jason Ricles wrote:
> I have an application that sends binary websocket messages between a
> class and the web application using a websocket server written in
> java.
> 
> The data being sent from the java class is encoded in a binary buffer
> with the bytes in ISO8859_1. However, when I receive the bytes on the
> websocket server and the web application end they are junk (such as
> -121, -116, etc.) and not encoded the correct way that they need to
> be.

The bytes are transmitted as unsigned on the wire (as required by the
WebSocket spec). Java handles them as signed. You need to convert them.
Something like (untested):

char c = b & 0xFF;

Mark


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

Re: Having Java websocket server in tomcat handle ISO8859_1

[tomcat]

On 08.02.2016 20:27, Jason Ricles wrote:

The message is built and sent in a javaclass connected to a websocket
server for the web application also written in java then the message
is passed to the webpage which uses javascript


1) on this list, do not "top post". See :
http://tomcat.apache.org/lists.html#tomcat-users  #6

2) this is now very confusing.  Are you talking about data flowing from the server to a 
bowser client, or from a browser client to the server, or both, and in what order ?

(maybe a little ASCII-graphic schema would help)

Anyway, if you are sending/receiving text data "disguised" as binary data, then you are 
responsible for making sure that both ends know which character set/encoding is being 
used, and *program* the proper encoding/decoding at both ends.


What you are seeing in the buffer right now is not junk. It is exactly what was written by 
the side doing the writing.  The problem is that the side doing the reading, does not know 
how this data is encoded, so it does not "understand" it properly.


For a websocket, there is no Tomcat setting (that I know of) that will change that. You 
will have to do this in your applications (on both server and client sides).


And if you instead want to exchange text data, then as far as I know (per RFC 6455) it 
MUST be encoded as UTF-8.

See https://tools.ietf.org/html/rfc6455#section-5.6



On Mon, Feb 8, 2016 at 2:25 PM, André Warnier (tomcat)  wrote:

On 08.02.2016 19:41, Jason Ricles wrote:


I have an application that sends binary websocket messages between a
class and the web application using a websocket server written in
java.

The data being sent from the java class is encoded in a binary buffer
with the bytes in ISO8859_1. However, when I receive the bytes on the
websocket server and the web application end they are junk (such as
-121, -116, etc.) and not encoded the correct way that they need to
be.

I was reading that this might be caused by something being set in my
websocket server and web application to use UTF-8 for the default and
not ISO8859_1.

Is there any way I can change my websocket server and my web
application which uses JavaScript to use ISO8859_1 instead of UTF-8?



Now is it Java, or JavaScript ? (earlier you say "sent from the java
class"..)





For a proper "correct" solution, the client sending text data to the server
should tell the server what character set/encoding is used for that data
(via some kind of "header" for example).  This way, the server could always
read that text data and decode it in the proper way.

If you are /sure/ that this server socket, now and in the future, will only
ever receive text data from this particular version of your client
java/javascript code, and that text will always be encoded as iso-8859-1,
then you should at least make sure that the server code which is reading and
decoding this data, does it as iso-8859-1, which is not the default
character set for java.
But by doing so, you are only moving the problem further in the future,
because as far as it looks right now, the usage of Unicode/UTF-8 will
increase, and the usage of iso-8859-x character sets will decrease over
time.




-
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: Empty *jsp_java file after upgrade to Tomcat 8.0.26

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yasi,

On 2/1/16 8:17 PM, Yasi Xi (yxi) wrote:
> Hi, Dear Mark T and all
> 
> Sorry to resend this mail. I don't quite understand Mark's comment
> on this problem.
> 
>  WHAT IS THE PROBLEM 
> 
> I'm doing Tomcat upgrade for my J2EE server. When Tomcat is
> upgraded from 7.0.54 to 8.0.26,
> 
> 1) I get lots of empty *_jsp.java files in
> /opt/apache-tomcat_1/work/Catalina/, for example:
> 
> /opt/apache-tomcat_1/work/Catalina/localhost/cmp0307l/org/apache/jsp/w
ebcomponents/jsp/globalpagenotfound_jsp.java
>
> 
/opt/apache-tomcat_1/work/Catalina/localhost/svc3000/org/apache/jsp/svcc
omponents/common/jsp/globalerror_jsp.java
> 
> 2) There're six Tomcat servers working in a round-robin manner.
> Each of the six Tomcat server has lots of empty *_jsp.java files,
> but they do not share the same group of empty *_jsp.java files. It
> appears random regarding which JSP file gets an empty *_jsp.java
> and in which Tomcat server.
> 
> 3) When I delete a single empty *_jsp.java file in a Tomcat server
> and restart Tomcat, the previous empty *_jsp.java is generated and
> not empty.
> 
> 4) Before Tomcat upgrade from 7.0.54 to 8.0.26,
> /opt/apache-tomcat_1 soft link points to
> /opt/apache-tomcat-7.0.54_1, after the upgrade, it points to
> /opt/apache-tomcat-8.0.26_1
> 
> 5) /opt/apache-tomcat-7.0.54_1 and /opt/apache-tomcat-8.0.26_1 are
> two separate directories. /opt/apache-tomcat-8.0.26_1 does not
> exist before the upgrade.
> 
> [root@jm3btc003 opt]# ll /opt/ total 68 lrwxrwxrwx   1 root
> nobody  22 Dec 23 01:21 apache-tomcat_1 ->
> apache-tomcat-8.0.26_1 drwx--   7 nobody   nobody4096 Dec
> 11 02:23 apache-tomcat-7.0.54_1 drwxr-x---   9 root nobody
> 4096 Nov 10 01:51 apache-tomcat-8.0.26_1 ...
> 
> 6) There are other empty files after upgrading to Tomcat 8.0.26,
> for example, the following picture files are created by Java
> process in a separate directory other than Tomcat directories, the
> picture files are empty:
> 
> -rw-rw 1 nobody nobody0 Jan 29 07:11 AQ_500/default.jpg 
> -rw-rw 1 nobody nobody0 Jan 28 19:04 BN_500/default.jpg 
> -rw-rw 1 nobody nobody0 Jan 28 21:05 CL_500/default.jpg 
> -rw-rw 1 nobody nobody0 Jan 28 19:00 CP_500/default.jpg 
> -rw-rw 1 nobody nobody0 Jan 28 20:05 DZ_500/default.jpg 
> -rw-rw 1 nobody nobody0 Jan 28 13:11 EG_500/default.jpg

Tomcat never writes .jpg files. Maybe you are out of disk space? Quota
problem? Active virus scanner stuck on files?

> 7) We have some tomcat-embed-*.7.0.30.jar files deployed and
> scanned by Tomcat. Will these tomcat-embed-*.7.0.30.jar impact the
> *_jsp.java generation under Tomcat 8.0.26?
> 
> /opt/txs/webapps/TXS/share/tomcat-embed-core-7.0.30.jar 
> /opt/txs/webapps/TXS/share/tomcat-embed-jasper-7.0.30.jar
> 
>  MARK'S COMMENT 
> 
> Do you empty the work directory as part of this upgrade? If not,
> you should.
> 
> Mark
> 
>  YASI'S QUESTIONS 
> 
> Sorry, Mark, I don't quite understand
> 
> 1) Why empty work directory as part of Tomcat upgrade?
> /opt/apache-tomcat-8.0.26_1 does not exist before the upgrade.
> Should I empty /opt/apache-tomcat-7.0.54_1/work directory?

I think Mark was thinking that you might have a separate CATALINA_BASE
which has a work/ directory independent of the CATALINA_HOME (where
Tomcat is actually installed). If you have one of those, it's
essential that you remove everything in CATALINA_BASE/work as part of
the Tomcat upgrade. Actually, I would always remove the contents of
the work/ directory even when upgrading between point-releases (e.g.
8.0.31 -> 8.0.32) since the JSP implementation isn't guaranteed to be
compatible across releases.

> 2) Is there any change of system IO (e.g. file read/write) in
> Tomcat 8 which may cause some file to be empty?

I don't believe there has been any change, here.

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

iEYEARECAAYFAla41nkACgkQ9CaO5/Lv0PDynACfUqz+4FN3fQRyC8coRAk6XjRx
f+gAmQFxrIiLXysYc8gPPZedCVu+BHhf
=wPad
-END PGP SIGNATURE-

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

Re: Having Java websocket server in tomcat handle ISO8859_1

[Jason Ricles]

The message is built and sent in a javaclass connected to a websocket
server for the web application also written in java then the message
is passed to the webpage which uses javascript

On Mon, Feb 8, 2016 at 2:25 PM, André Warnier (tomcat)  wrote:
> On 08.02.2016 19:41, Jason Ricles wrote:
>>
>> I have an application that sends binary websocket messages between a
>> class and the web application using a websocket server written in
>> java.
>>
>> The data being sent from the java class is encoded in a binary buffer
>> with the bytes in ISO8859_1. However, when I receive the bytes on the
>> websocket server and the web application end they are junk (such as
>> -121, -116, etc.) and not encoded the correct way that they need to
>> be.
>>
>> I was reading that this might be caused by something being set in my
>> websocket server and web application to use UTF-8 for the default and
>> not ISO8859_1.
>>
>> Is there any way I can change my websocket server and my web
>> application which uses JavaScript to use ISO8859_1 instead of UTF-8?
>
>
> Now is it Java, or JavaScript ? (earlier you say "sent from the java
> class"..)
>
>>
>
> For a proper "correct" solution, the client sending text data to the server
> should tell the server what character set/encoding is used for that data
> (via some kind of "header" for example).  This way, the server could always
> read that text data and decode it in the proper way.
>
> If you are /sure/ that this server socket, now and in the future, will only
> ever receive text data from this particular version of your client
> java/javascript code, and that text will always be encoded as iso-8859-1,
> then you should at least make sure that the server code which is reading and
> decoding this data, does it as iso-8859-1, which is not the default
> character set for java.
> But by doing so, you are only moving the problem further in the future,
> because as far as it looks right now, the usage of Unicode/UTF-8 will
> increase, and the usage of iso-8859-x character sets will decrease over
> time.
>
>
>
>
> -
> 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: Having Java websocket server in tomcat handle ISO8859_1

[tomcat]

On 08.02.2016 19:41, Jason Ricles wrote:

I have an application that sends binary websocket messages between a
class and the web application using a websocket server written in
java.

The data being sent from the java class is encoded in a binary buffer
with the bytes in ISO8859_1. However, when I receive the bytes on the
websocket server and the web application end they are junk (such as
-121, -116, etc.) and not encoded the correct way that they need to
be.

I was reading that this might be caused by something being set in my
websocket server and web application to use UTF-8 for the default and
not ISO8859_1.

Is there any way I can change my websocket server and my web
application which uses JavaScript to use ISO8859_1 instead of UTF-8?


Now is it Java, or JavaScript ? (earlier you say "sent from the java class"..)





For a proper "correct" solution, the client sending text data to the server should tell 
the server what character set/encoding is used for that data (via some kind of "header" 
for example).  This way, the server could always read that text data and decode it in the 
proper way.


If you are /sure/ that this server socket, now and in the future, will only ever receive 
text data from this particular version of your client java/javascript code, and that text 
will always be encoded as iso-8859-1, then you should at least make sure that the server 
code which is reading and decoding this data, does it as iso-8859-1, which is not the 
default character set for java.
But by doing so, you are only moving the problem further in the future, because as far as 
it looks right now, the usage of Unicode/UTF-8 will increase, and the usage of iso-8859-x 
character sets will decrease over time.





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

Relative redirects in light of recent changes

[George Stanchev]

Hi,

Recent changes to Tomcat altered the behavior of our applications a bit so I've 
got couple of questions. The versions in questions are 7.0.64 and 7.0.67. I am 
aware of which is also described in the changelog for 7.0.67.

I have a filter acts on application "/myapp" that does a redirect in the 
following manner:

httpResponse.sendRedirect("login?a=b=d")

In Tomcat 7.0.65 I can see the following flow (the text after the 302 below is 
the value of the "Location" header as seen by network sniffer):

GET http://hostname/myapp?m=n=p  
  ==> 302: "http://hostname/myapp/?m=n=p;
GET http://hostname/myapp/?m=n=p 
  ==> 302: "http://hostname/myapp/login?a=b=d;

The first redirect adds a trailing slash after "myapp", the second is generated 
by my redirect

In Tomcat 7.0.67 with no "useRelativeRedirects" set on the context (which 
defaults it to "true"), I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "login?a=b=d"

Now, this is expected behavior given the fix for [1]

However, with useRelativeRedirects="false" I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "http://hostname/login?a=b=d;

The questions I have are 2: First, what happened with the trailing slash 
redirect. I vaguely remember discussions around it but I couldn't find them on 
the mailing list search index. And secondly but more importantly, in 7.0.64, 
the HttpServletRequest.sendRedirect() would use the application name to form 
the Location header value (as in .../myapp/login...) whereas in 7.0.67 the name 
of the application is missing from the absolute redirect.

Is there any way to work around this and to have 7.0.67 behave like 7.0.64?

George

[1] http://bz.apache.org/bugzilla/show_bug.cgi?id=56917
[2] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html

Re: Having Java websocket server in tomcat handle ISO8859_1

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

On 2/8/16 3:43 PM, Mark Thomas wrote:
> On 08/02/2016 18:41, Jason Ricles wrote:
>> I have an application that sends binary websocket messages
>> between a class and the web application using a websocket server
>> written in java.
>> 
>> The data being sent from the java class is encoded in a binary
>> buffer with the bytes in ISO8859_1. However, when I receive the
>> bytes on the websocket server and the web application end they
>> are junk (such as -121, -116, etc.) and not encoded the correct
>> way that they need to be.
> 
> The bytes are transmitted as unsigned on the wire (as required by
> the WebSocket spec). Java handles them as signed. You need to
> convert them. Something like (untested):
> 
> char c = b & 0xFF;

I had to read this something like 10 times before I convinced myself
that this was correct. For those who want to know what this makes any
kind of sense (because, at first glance, it does not make any sense),
I'll explain it.

For starters, Java uses signed byte primitives but /unsigned/ char
primitives. For those coming from the C world, that may be confusing.
bytes are 8 (signed) bits and chars are 16 (unsigned) bits.

But Java doesn't have any defined arithmetic operations (including
bitwise) for anything smaller than an int (32 signed bytes), so the
above assignment is actually more like this:

byte b = 0xab; // e.g.
char c = (char)  ( ((int)b) & 0xff )

So, first b is widened from 8 bits to 32 bits -- with a
sign-extension. That means that -1 is still -1, it's just represented
by a different bit pattern:        
instead of  .

Next, the bitwise && is performed, which zeros-out everything but the
bottom 8-bits (now we have      ). Then, that
value is cast to char which does practically nothing.

In the above example (-1), we get a final value of 255 for c, which is
exactly what you'd expect for an unsigned char whose signed value is -1.

I think the only surprise thing there is that Java widens all types to
32-bit signed int to perform these operations. Without that fact, the
above assignment doesn't make much sense. In C, that line of code
would do absolutely nothing at all.

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

iEYEARECAAYFAla5FywACgkQ9CaO5/Lv0PCvlACfXaUtdj7t6VhKJxTUsurCOeqS
6jgAoJ3Vw1/L2UHatpFN4iDPnLL7JCxH
=7P38
-END PGP SIGNATURE-

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

RE: Relative redirects in light of recent changes

[George Stanchev]

Hi,

Recent changes to Tomcat altered the behavior of our applications a bit so I've 
got couple of questions. The versions in questions are 7.0.64 and 7.0.67. I am 
aware of which is also described in the changelog for 7.0.67.

I have a filter acts on application "/myapp" that does a redirect in the 
following manner:

httpResponse.sendRedirect("login?a=b=d")

In Tomcat 7.0.65 I can see the following flow (the text after the 302 below is 
the value of the "Location" header as seen by network sniffer):

GET http://hostname/myapp?m=n=p  
  ==> 302: "http://hostname/myapp/?m=n=p;
GET http://hostname/myapp/?m=n=p 
  ==> 302: "http://hostname/myapp/login?a=b=d;

The first redirect adds a trailing slash after "myapp", the second is generated 
by my redirect

In Tomcat 7.0.67 with no "useRelativeRedirects" set on the context (which 
defaults it to "true"), I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "login?a=b=d"

Now, this is expected behavior given the fix for [1]

However, with useRelativeRedirects="false" I see

GET http://hostname/myapp?m=n=p 
  ==> 302: "http://hostname/login?a=b=d;

The questions I have are 2: First, what happened with the trailing slash 
redirect. I vaguely remember discussions around it but I couldn't find them on 
the mailing list search index. And secondly but more importantly, in 7.0.64, 
the HttpServletRequest.sendRedirect() would use the application name to form 
the Location header value (as in .../myapp/login...) whereas in 7.0.67 the name 
of the application is missing from the absolute redirect.

Is there any way to work around this and to have 7.0.67 behave like 7.0.64?

George

[1] http://bz.apache.org/bugzilla/show_bug.cgi?id=56917
[2] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html



Stepped through the code, and what I thought it is an irrelevant question (what 
happened to the trailing slash redirect) might hold the key to the problem.

In org.apache.catalina.connector.Response#toAbsolute(String 
location="login?a=b=d")
...
boolean leadingSlash = location.startsWith("/"); // evaluates to false since 
it’s a relative URI
...
if (!leadingSlash) { // false so we go in
String relativePath = request.getDecodedRequestURI(); // 
evaluates to "/myapp"
int pos = relativePath.lastIndexOf('/'); // evaluates to 0
...
encodedURI = urlEncoder.encodeURL(relativePath, 0, pos); // pos is 0 so 
encodedURI is empty
...
redirectURLCC.append(encodedURI);  // " http://hostname + "" => same URL
redirectURLCC.append('/');
redirectURLCC.append(location, 0, location.length()); final: 
"http://hostname/login?a=b=d; which is a wrong URL...

"http://hostname/myapp/?m=n=p; (with trailing slash before ?) works just fine.

So my question becomes - how do I make it add the trailing slash as in 7.0.64...

George

Re: Relative redirects in light of recent changes

[Mark Thomas]

On 08/02/2016 21:55, George Stanchev wrote:
> 
> 
> Hi,
> 
> Recent changes to Tomcat altered the behavior of our applications a bit so 
> I've got couple of questions. The versions in questions are 7.0.64 and 
> 7.0.67. I am aware of which is also described in the changelog for 7.0.67.

There are two changes that are interacting here.

The first is moving the directory redirect from the Mapper to the
default servlet. This is:
mapperContextRootRedirectEnabled
and
mapperDirectoryRedirectEnabled

The default for both of these in 7.0.67 was false. In 7.0.68 the default
for mapperContextRootRedirectEnabled is going to change to true because
of issues like those you describe.

The second is allowing relative redirects.

> I have a filter acts on application "/myapp" that does a redirect in the 
> following manner:
> 
> httpResponse.sendRedirect("login?a=b=d")
> 
> In Tomcat 7.0.65 I can see the following flow (the text after the 302 below 
> is the value of the "Location" header as seen by network sniffer):
> 
> GET http://hostname/myapp?m=n=p  
>   ==> 302: "http://hostname/myapp/?m=n=p;
> GET http://hostname/myapp/?m=n=p 
>   ==> 302: "http://hostname/myapp/login?a=b=d;
> 
> The first redirect adds a trailing slash after "myapp", the second is 
> generated by my redirect

So here the flow is
- request 1 received
- Mapper adds / and redirects
- request 2 (with trailing /) received
- Filter redirects (absolute)

> In Tomcat 7.0.67 with no "useRelativeRedirects" set on the context (which 
> defaults it to "true"), I see

Here the flow is
- request 1 received
- Filter redirects

The problem is that the filter generates the wrong redirect because it
expects the trailing / to be present.

Now you could argue that the Filter should handle this but most Filters
won't.

> GET http://hostname/myapp?m=n=p 
>   ==> 302: "login?a=b=d"
> 
> Now, this is expected behavior given the fix for [1]
> 
> However, with useRelativeRedirects="false" I see
> 
> GET http://hostname/myapp?m=n=p 
>   ==> 302: "http://hostname/login?a=b=d;
> 
> The questions I have are 2: First, what happened with the trailing slash 
> redirect. I vaguely remember discussions around it but I couldn't find them 
> on the mailing list search index. And secondly but more importantly, in 
> 7.0.64, the HttpServletRequest.sendRedirect() would use the application name 
> to form the Location header value (as in .../myapp/login...) whereas in 
> 7.0.67 the name of the application is missing from the absolute redirect.
> 
> Is there any way to work around this and to have 7.0.67 behave like 7.0.64?

Setting mapperContextRootRedirectEnabled="true" on the Context should
fix it.

Mark


> 
> George
> 
> [1] http://bz.apache.org/bugzilla/show_bug.cgi?id=56917
> [2] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html
> 
> 
> 
> Stepped through the code, and what I thought it is an irrelevant question 
> (what happened to the trailing slash redirect) might hold the key to the 
> problem.
> 
> In org.apache.catalina.connector.Response#toAbsolute(String 
> location="login?a=b=d")
> ...
> boolean leadingSlash = location.startsWith("/"); // evaluates to false since 
> it’s a relative URI
> ...
> if (!leadingSlash) { // false so we go in
> String relativePath = request.getDecodedRequestURI(); // 
> evaluates to "/myapp"
> int pos = relativePath.lastIndexOf('/'); // evaluates to 0
> ...
> encodedURI = urlEncoder.encodeURL(relativePath, 0, pos); // pos is 0 so 
> encodedURI is empty
> ...
> redirectURLCC.append(encodedURI);  // " http://hostname + "" => same URL
> redirectURLCC.append('/');
> redirectURLCC.append(location, 0, location.length()); final: 
> "http://hostname/login?a=b=d; which is a wrong URL...
> 
> "http://hostname/myapp/?m=n=p; (with trailing slash before ?) works just 
> fine.
> 
> So my question becomes - how do I make it add the trailing slash as in 
> 7.0.64...
> 
> George
> 
> 
> 
> 
> -
> 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: Having Java websocket server in tomcat handle ISO8859_1

[tomcat]

On 08.02.2016 23:31, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

All,

On 2/8/16 3:43 PM, Mark Thomas wrote:

On 08/02/2016 18:41, Jason Ricles wrote:

I have an application that sends binary websocket messages
between a class and the web application using a websocket server
written in java.

The data being sent from the java class is encoded in a binary
buffer with the bytes in ISO8859_1. However, when I receive the
bytes on the websocket server and the web application end they
are junk (such as -121, -116, etc.) and not encoded the correct
way that they need to be.


The bytes are transmitted as unsigned on the wire (as required by
the WebSocket spec). Java handles them as signed. You need to
convert them. Something like (untested):

char c = b & 0xFF;


I had to read this something like 10 times before I convinced myself
that this was correct. For those who want to know what this makes any
kind of sense (because, at first glance, it does not make any sense),
I'll explain it.

For starters, Java uses signed byte primitives but /unsigned/ char
primitives. For those coming from the C world, that may be confusing.
bytes are 8 (signed) bits and chars are 16 (unsigned) bits.

But Java doesn't have any defined arithmetic operations (including
bitwise) for anything smaller than an int (32 signed bytes), so the
above assignment is actually more like this:

byte b = 0xab; // e.g.
char c = (char)  ( ((int)b) & 0xff )

So, first b is widened from 8 bits to 32 bits -- with a
sign-extension. That means that -1 is still -1, it's just represented
by a different bit pattern:        
instead of  .

Next, the bitwise && is performed, which zeros-out everything but the
bottom 8-bits (now we have      ). Then, that
value is cast to char which does practically nothing.

In the above example (-1), we get a final value of 255 for c, which is
exactly what you'd expect for an unsigned char whose signed value is -1.

I think the only surprise thing there is that Java widens all types to
32-bit signed int to perform these operations. Without that fact, the
above assignment doesn't make much sense. In C, that line of code
would do absolutely nothing at all.



Would a simpler way to say this not be that in Java, a char is a 16-bit integer whose 
value happens to be the corresponding character's Unicode codepoint ?


Of course his all takes us further away from the OP's original description of the issue, 
which said "The data being sent from the java class is encoded in a binary

buffer with the bytes in ISO8859_1."
Which basically doesn't make sense, unless the data in question is originallly 
text.



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