- Original Message -
From: Remy Maucherat <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 11, 2001 1:47 PM
Subject: Re: Using JNDI with Jakarta-Tomcat 4.0 beta 3
> > Hi,
> >
> > I have been using Jakarta-Tomcat 3.2.1 and when I upgraded to the 4.0
beta
> 3
> > I have
In the Java world, varchar should support UNICODE characters, not 8-bit
bytes.
Yes, I know some data bases do not store UNICODE, but some (Oracle,
InstantDB etc) do. The other problem with character, is character encoding,
when/if the encoding of the application does not match the native characte
According to NamingManager documentation, first it will look for
'org.jnp.interfaces.java.javaURLContextFactory' which does not exist, so it
should next look for 'org.apache.naming.java.javaURLContextFactory' which
does exist.
So, this should work.
BTW, the 'org.apache.naming' prefix is concatenat
The EJB 2.0 Draft specification does specify via as the
connection between different EJB containers. Also, all naming lookup does
go through a JNDI interface usually starting at a local InitialContext.
I can send you the section describing this in the EJB specification on
Monday.
- Origina
Where is the interface document for tomcat object factories?
I would like to have an object factory for JBoss context.
- Original Message -
From: Remy Maucherat <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, March 09, 2001 7:13 PM
Subject: Re: Implementation in 4.0.b1
> > I
- Original Message -
From: Guillaume Rousse <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 21, 2001 7:23 AM
Subject: Re: Tomcat file locations on Unix
> On 2001.02.21 13:18:00 +0400 Rolf Veen wrote:
> > > From what i'm seeing on my own system (Mandrake 7.2), gener
You will still need to fix the actual parameter parsing routine to delay
applying the encoding until the name and parameter are parsed out of the
input stream...
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 12, 2001 1:14 PM
Subject: Re: cha
Title: charset used for parameters decoding on HTTP request Tomcat3.x,4
Because of the way byte values are URL encoded, (and the way tomcat decodes
them.) What you usually receive with get parameters is a byte stream one byte
per character. You can post process the string obtained by getParam
UTF-16 is not an acceptable encoding for XML as it takes two bytes per
character, is byte order sensitive, and the XML tags would not be
recognized...
UTF-8 is the correct encoding! Any 31 bit character in the ISO10646
specification can be correctly represented in UTF-8. UNICODE is the first
657
Sounds good to me.
Tim
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 02, 2001 11:58 PM
Subject: Bugzilla categories
> Hi,
>
> What about another category - "Encoding" for all encoding-related bugs ?
> ( that would include all "special chars
Since characters in Java are UNICODE, what does this code do when it encounters a
character who's code point is greater than 0xFF?
My suggestion, is to first encode the path as a UTF-8 byte array, then encode the
bytes according to this algorithm
Tim
[EMAIL PROTECTED] wrote:
> remm01/0
d in this release also. At
least use the value of ServletRequest.setCharacterEncoding() to specify the encoding
of parameter names and values. (BugRat #785).
I will do the work on this one.
And, If my vote counts +1
Tim Tye
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
12 matches
Mail list logo
