Re: Using JNDI with Jakarta-Tomcat 4.0 beta 3
- 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 a propblem with my JNDI configuration.
I have a servlet that uses an EJB container that requires the following
"jndi.properties" :
java.naming.factory.initial
com.sun.jndi.rmi.registry.RegistryContextFactory
java.naming.provider.url rmi://localhost:1099
java.naming.factory.url.pkgs org.objectweb.jonas.naming
With 3.2.1 I just needed to make sure that I had my jndi.properties file
on
the classpath, with 4.0 beta 3 I do not seem to be able to get this read
by
any means. The only mechanism that I found to get this to work is if I
call
"System.setProperty()" in my servlet just before I call "new
javax.naming.InitialContext()". If I do not do this I get the following
error message:
javax.naming.NoInitialContextException: Cannot instantiate class:
org.apache.naming.java.javaURLContextFactory. Root exception is
java.lang.ClassCastException:
org.apache.naming.java.javaURLContextFactory
Can anyone tell me how I am supposed to set this for my servlet? I tried
the
following without any success:
1) Using env-entry in my WEB-INF/web.xml
2) Putting the jndi.properties into the classpath
That will fail, since Catalina ignores your classpath.
Try putting the jndi.properties in common/classes/jndi.properties. It
should
work better.
Note that to use JNDI related stuff (esp with load-on-startup), I
recommend
using the latest nightly.
Remy
I have also had success in 4.0 B2 setting the -D
java.naming.factory.url.pkgs=org.objectweb.jonas.naming
parameter on Tomcat Start script.
Then I use ctx.lookup("rmi://localhost:1099"); to obtain the context of the
ejb server.
Also, 4.0 B2 supports the ejb-ref tags including the full redirection of
the lookup to the EJB server (via url factory context)..
Tim
Re: JDBC-Session store
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 character encoding of the table, a translation is performed, and the results are not always reversible. The correct type used to store serialized data is byte, or varbyte, or even blob. Remember, Java characters are unsigned sixteen bit numbers not eight bit data elements (called char by 'C', 'C++' and many databases). - Original Message - From: Krishna R. Baddam [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 28, 2001 7:25 PM Subject: RE: JDBC-Session store Blob is a bad idea. Serialize the objects and store them as varchar. We implemented a home grown session store and the varchar route works lot better. I believe IBM's WebSphere session store also uses varchars. Krishna -Original Message- From: Bip Thelin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 2:13 AM To: [EMAIL PROTECTED] Subject: JDBC-Session store I've been looking at the FileStore implementation and you(Kief/Craig) basically store a java object in the textfile, using the same approach with a DB usually(?!) involves using a SQL3 capable RDBMS i.e. Oracle, since you probably want to store the object as a Blob or might even work with a STRUCT. Anyway, I'm kind of reluctant to save objects in to a RDBMS and sort or "overriding" the native formats. Have anyone got any ideas on how to solve this in a good way? Preferably so it would work with JDBC 2.0 i.e., not use SQL3 datatypes. Otherwise I'll just go ahead and implement it as either a blob or a STRUCT whichever works out best. Thanks, Bip
Re: Strange problem with URL_PKG_PREFIXES
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 concatenated onto the URL prefixes by
jakarta. Also, when the jnp.jar is removed, it still fails with the same
error.
How can this be made to work?
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, March 13, 2001 5:49 PM
Subject: Re: Strange problem with URL_PKG_PREFIXES
The Context.URL_PKG_PREFIXES environment variable is a colon-seperated
list
of package prefixes. However, when I set this environment variable to
"org.jnp.interfaces:org.apache.naming" and attempt to get a Context;
Context ctx = new InitialContext().lookup("java:/comp");
The lookup fails with:
javax.naming.ConfigurationException: Provider URL missing
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:702)
However, when I set this environment variable to
"org.apache.naming:org.jnp.interfaces"
The lookup succeeds!
"org.jnp.interfaces" only contains one class and that is
"org.jnp.interfaces.jnp.jnpURLContextFactory".
It seems to me that the lookup code is not correctly parsing the
Context.URL_PKG_PREFIXES environment variable.
It looks like the JNP InitialContext has a custom way to retrieve URL
contexts.
It's supposed to call NamingManager.getURLContext (see the
javax.naming.InitialContext source code for more details).
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: ejb-ref ejb-link Implementation in 4.0.b1
The EJB 2.0 Draft specification does specify ejb-ref via ejb-link 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. - Original Message - From: Aaron Mulder [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 10, 2001 7:40 AM Subject: Re: ejb-ref ejb-link Implementation in 4.0.b1 I'm a little confused by all of the discussion around this. Acoording to the spec, the ejb-link is supposed to have the name of an EJB deployed in the same application unit. In other words, no JNDI stuff, no factories, just a name. "MyBean", or whatever. If Tomcat wants you to put JNDI stuff in there, isn't that an abuse of the spec? Shouldn't Tomcat be using a separate server-specific deployment descriptor to provide the extra information to reference beans that are in a different application (i.e. those that require cusotm JNDI settings)? Aaron On Fri, 9 Mar 2001 [EMAIL PROTECTED] wrote: Weining Qi writes: if you are running tomcat 3.x in the same window (tomcat run), look at the feedback from tomcat when call the ejb that way, you can see that tomcat does not recognize the namespace "java:com/env/" for calling ejb as The name is "java:comp/ejb" NOT --. And yes tomcat does recognize it Because it is defined in web.xml as shown in the snip. the sun j2ee specification v1.3. you should call ejb directly by its jndi name, which you gave when you deployed it. I tried that, it does not work. I get "NamingException". Note: the EJB is deployed in a different machine than tomcat. When I try to open the context to that machine directly from a servlet in tomcat, I get: javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory. Root exception is java.lang.ClassCastException: org.jnp.interfaces.NamingContextFactory at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:659) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:250) at javax.naming.InitialContext.init(InitialContext.java:226) at javax.naming.InitialContext.init(InitialContext.java:202) at SimpleServlet.printContextInfo(SimpleServlet.java:168) at SimpleServlet.doIt(SimpleServlet.java:99) at SimpleServlet.doGet(SimpleServlet.java:30) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher. java:573) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatch er.java:321) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher .java:236) at org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java :386) at org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:215) at filters.ExampleFilter.doFilter(ExampleFilter.java:140) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:180) at filters.ExampleFilter.doFilter(ExampleFilter.java:140) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:180) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:251) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:196) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:464) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161 ) at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :159) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977) at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java: 818) at
Re: ejb-ref ejb-link Implementation in 4.0.b1
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: ejb-ref ejb-link Implementation in 4.0.b1
I am trying to obtain a remote reference to an EJB in another machine.
I have set the ejb-ref in web.xml as follows:
ejb-ref
descriptionSample bean generated by coolgen placed here for ease
of
early testing/description
ejb-ref-nameejb/S_STRESS_32K/ejb-ref-name
ejb-ref-typeSession/ejb-ref-type
homecool.models.coop07.java.S_STRESS_32KpsHome/home
remotecool.models.coop07.java.S_STRESS_32Kps/remote
ejb-linkjndi:/ttt1.ca.com:1099/S_STRESS_32Kps/ejb-link
/ejb-ref
However, when I do ctx.lookup("java:/comp/ejb/S_STRESS_32K") I get a
null
reference instead of the necessary remote reference to the home
interface.
Is ejb-link implemented and documented?
Which code is involved in ejb-link lookup?
Is this fixed in the latest 4.0?
Tomcat 4 will parse the web.xml file and bind references to the specified
resources in the naming environment. To be able to resolve those
references,
TC needs an appropriate object factory. If no object factory is available,
null is returned when you do a lookup.
Right now, there are two factories :
- one for getting Tyrex managed data sources
- one for getting Tyrex UserTransactions
You can easily add additional factories for additional resource types
(EJBs,
JMS resources ...). Contributed object factories (provided they are
generic
enough) could be added to the repository.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat file locations on Unix
- 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), general services (ftp, www, etc) have their own /var/name dir, while specific applications (postgres, wine, etc...) have their /var/lib/name dir. $PKGS/tomcat/ /conf /bin /lib /doc /src /log(a symlink to /var/log/tomcat as a last resort) /META-INF (yes, a meta directory to be used by generic tools) The beauty of Unix is that a product may be installed anywhere the product designers want, then the directories moved to where the need to be with symlink providing the connection between simple design, and safe usable file system layout. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: charset used for parameters decoding on HTTP request Tomcat3.x,4
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 getParameter by converting it back to a byte array, then convert to a string and specify the encoding. - Original Message - From: Adalbert Wysocki To: [EMAIL PROTECTED] Sent: Monday, February 12, 2001 12:00 PM Subject: charset used for parameters decoding on HTTP request Tomcat3.x,4 Hi all, I would like to know the policy for the request's parameters decoding in Tomcat 3.x. In Servlet 2.3 specifications a new method on the HttpServletRequest object was added in order to be able to specify the request's parameters charset encoding. This charset is used futhermore while the parameters parsing. This method is implemented in Tomcat 4. What is about Tomakat 3.2 implementing the servlet 2.2 specifications where the charset for parameters' decoding cannot be specified and considering that browsers never send the form encoding charset in th erequests' headers. In the case pages generated by my servlet run with Tomcat 3.2 are UTF-8 encoded, and requests for theses pages contain UTF-8 encoded parameters, how can I specify to the servlet engine running my servlet to decode parameters from UTF-8 and not using the default plateform encoding (8859-J, Shift_JIS (for japan plateforms)...). These are my questions: --- - is Tomcat 3.2 supports double byte encoded parameters (I sew that parameters are parsed with javax.servlet.http.HttpUtils that does not support double byte encoded parameters) - if it is possible, how to do it. NB: A solution would be to overwrite the system property "file.encoding" on the command line. But on exotic platforms (such as Korean), overwriting the property "file.encoding" on the command line while the servlet engine starting is not taken under consideration while the default characters-bytes/bytes-characters converters instantiation (this behavior is listed in Sun's bugs list but is not considered as a bug). In these cases the default plateform encoding is used. Adalbert Adalbert Wysocki, software engineer mailto:[EMAIL PROTECTED] phone: +33 (0)1 71.00.68.67 fax: +33 (0)1 71.00.68.02
Re: charset used for parameters decoding on HTTP request Tomcat3.x,4
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: charset used for parameters decoding on HTTP request Tomcat3.x,4 I would like to know the policy for the request's parameters decoding in Tomcat 3.x. AFAIK there are still problems in both 3.2.x and 3.3(dev). Fixing this is one of the highest things on my todo list, and you should expect a solution before 3.3 beta ( i.e. in about a month ). The solution will likely use a special module that will try to "guess" the encoding using the common hints ( Content-Type, Accept-Language, the common solution of passing a charset parameter ). It is not possible to use the setCharset() method from Servlet2.3 - but in most cases you'll not have to. Good Idea. BTW, Netscape navigator 4.7x seems to return the charset header value when it is not the same as the default encoding. Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: serializing XML to a ServletOutputStream fails
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
65768 characters of ISO10646.
A CKJ character code point value of 0x6123 is represented in UTF-8 as three
bytes E6 84 A3.
What byte values are you seeing for the encoding of a given Chinese code
point?
- Original Message -
From: Zhu Ming [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, February 05, 2001 4:24 AM
Subject: RE: serializing XML to a ServletOutputStream fails
Hi,
Maybe you should not use character set "UTF-8". I remember
that it's 8-bit Unicode. As I know, Chinese and Korean has
16-bit code. So at least, you should try 16-bit Unicode.
I forgot the name, maybe it's "UTF-16". But I'm not sure if
JDK have fully support to "UTF-16".
I'm not an Unicode expert. I'll be happy if what I say can
be a hint to solve this problem.
Ming
-Original Message-
From: Michael Mealling [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 05, 2001 03:04
To: [EMAIL PROTECTED]
Subject: serializing XML to a ServletOutputStream fails
(This might be a bug so I'm cc-ing to tomcat-dev)
Hi,
I'm trying to serialize some XML out to a ServletOutputStream but
the resulting XML on the client side contains corrupted Unicode
characters (the DOM I'm serializing out contains Chinese, Korean,
English, etc). Here's the code in question:
response.setContentType("text/xml; charset=UTF-8");
ServletOutputStream out = response.getOutputStream();
out.print("?xml version=\"1.0\" encoding=\"UTF-8\"?\n" +
"!DOCTYPE cnrp PUBLIC \"-//IETF//DTD CNRP 1.0//EN\"" +
" \"http://www.ietf.org/cnrp.dtd\"\n");
out.flush();
OutputFormat format = new OutputFormat(document);
format.setOmitXMLDeclaration(true);
format.setIndenting(true); // it makes debuggin easier
format.setEncoding("UTF-8"); // this is the default anyway
XMLSerializer serializer = new XMLSerializer(out, format);
serializer.serialize(document.getDocumentElement());
The XML that the client gets is fine except that the non-ASCII subset
of the UTF-8 encoded Unicode characters are garbled. I can serialize
the XML out to a FileOutputStream and it works just fine.
I'm running Tomcat 3.2.1 that's the backend for a remote
Apache 1.3.17 server using ajp13 (and thus mod_jk).
This code looks like its the right way to do this but either
I've hit a bug or else I'm missing something (an encoding somewhere
between a Stream and a Writer?)
-MM
--
--
--
Michael Mealling | Vote Libertarian! | www.rwhois.net/michael
Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#:
14198821
Network Solutions | www.lp.org | [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Bugzilla categories
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", charsets, etc). It's a big issue and I want to have all the related bugs grouped togheter. ( I'll work on them - but it's not easy and will take few weeks to sort it out ) -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets DefaultServlet.java
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/01/29 19:50:09
Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
Log:
- Will now encode all unsafe characters on the URL.
Revision ChangesPath
1.22 +84 -28
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
Index: DefaultServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- DefaultServlet.java 2001/01/25 05:45:40 1.21
+++ DefaultServlet.java 2001/01/30 03:50:08 1.22
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.21 2001/01/25 05:45:40 remm Exp $
- * $Revision: 1.21 $
- * $Date: 2001/01/25 05:45:40 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
1.22 2001/01/30 03:50:08 remm Exp $
+ * $Revision: 1.22 $
+ * $Date: 2001/01/30 03:50:08 $
*
*
*
@@ -76,6 +76,7 @@
import java.io.Reader;
import java.io.InputStreamReader;
import java.io.Writer;
+import java.io.OutputStreamWriter;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLEncoder;
@@ -87,6 +88,7 @@
import java.util.Locale;
import java.util.TimeZone;
import java.util.Hashtable;
+import java.util.BitSet;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.security.MessageDigest;
@@ -119,7 +121,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.21 $ $Date: 2001/01/25 05:45:40 $
+ * @version $Revision: 1.22 $ $Date: 2001/01/30 03:50:08 $
*/
public class DefaultServlet
@@ -219,6 +221,40 @@
StringManager.getManager(Constants.Package);
+/**
+ * Array containing the safe characters set.
+ */
+protected static BitSet safeCharacters;
+
+
+protected static final char[] hexadecimal =
+{'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
+ 'A', 'B', 'C', 'D', 'E', 'F'};
+
+
+// - Static Initializer
+
+
+static {
+ safeCharacters = new BitSet(256);
+ int i;
+ for (i = 'a'; i = 'z'; i++) {
+ safeCharacters.set(i);
+ }
+ for (i = 'A'; i = 'Z'; i++) {
+ safeCharacters.set(i);
+ }
+ for (i = '0'; i = '9'; i++) {
+ safeCharacters.set(i);
+ }
+ safeCharacters.set('-');
+ safeCharacters.set('_');
+ safeCharacters.set('.');
+ safeCharacters.set('*');
+ safeCharacters.set('/');
+}
+
+
// - Public Methods
@@ -853,7 +889,7 @@
replaceChar +
normalized.substring(index + 3);
}
-
+
// Normalize the slashes and add leading slash if necessary
if (normalized.indexOf('\\') = 0)
normalized = normalized.replace('\\', '/');
@@ -902,29 +938,49 @@
* @param path Path which has to be rewiten
*/
protected String rewriteUrl(String path) {
-
-String normalized = path;
-
- // Replace " " with "%20"
-while (true) {
- int index = normalized.indexOf(" ");
- if (index 0)
- break;
- normalized = normalized.substring(0, index) + "%20"
- + normalized.substring(index + 1);
- }
-
- // Replace "" with "%26"
-while (true) {
- int index = normalized.indexOf("");
- if (index 0)
- break;
- normalized = normalized.substring(0, index) + "%26"
- + normalized.substring(index + 1);
- }
-
-return normalized;
-
+
+/**
+ * Note: This code portion is very similar to URLEncoder.encode.
+ * Unfortunately, there is no way to specify to the URLEncoder which
+ * characters should be encoded. Here, ' ' should be encoded as "%20"
+ * and '/' shouldn't be encoded.
+ */
+
+ int maxBytesPerChar = 10;
+int caseDiff = ('a' - 'A');
+StringBuffer rewrittenPath =
