> This doesn't seem to happen with the standard.jar and I'm totally > copying its layout and the version information at the beginning of the > file accept for the encoding being UTF-8 instead of ISO...
Well, I notice that the standard jar also stores the files under thier own names and not /meta-inf/taglib.tld. I would suspect this is why this error doesn't show up with the standard taglib, and probibly with any of the other taglibraries at Jakarta as well, because they all do not use the /meta-inf/taglib.tld convention outlined in the JSP specification. They all bank on the new clauses which say you can put the taglib under any name in the /meta-inf/ as long as it has a tld. extension. But I bet this particular clause isn't tested in Jasper/Tomcat yet? Plus I notice that the jakarta taglibs also reley on the the tld being in the WEB-INF instead of in the Jar. The one in the Jar is never really getting used! The one in WEB-INF is getting loaded. I bet this is a bug. It smells like a bug to me... > > The beginning of my files look like this > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag > Library 1.2//EN" > "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd";> > <taglib> > <tlib-version>1.1</tlib-version> > <jsp-version>1.2</jsp-version> > <short-name>Conditional</short-name> > > The beginning of the standard.jar files looks like this > <?xml version="1.0" encoding="ISO-8859-1"?> > <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag > Library 1.2//EN" > "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd";> > <taglib> > <tlib-version>1.0</tlib-version> > <jsp-version>1.2</jsp-version> > > I'm generating my tld files using Forte4J because I like the code > generation capabilities. It forces the tld files to be UTF-8. I really > don't think that should be so much of a problem. Expecially if when > the tld is outside of the jar it working fine. This seems to be > something to do with the mechanism that gets the tld from the Jar file > (which I have absolutely no knowledge of, or want to explore in any > detail personally). Could it be trying to force a specific encoding > onto the parser? Or could it not be setting the encoding appropriately > in the parser. I know that when you set a Char/Stream to the parser > you have tell the parser its encoding. I would suspect there is a > difference in the code between pulling from the Jar vs. Pulling it > from the file. Probibly something like getting the resource from a > JarUrlConnection vs pulling it from some resource location. > > I'll play with the encodings again, but I doubt it will effect > anything in the long run. Again, I don't get any problems from > validating this file directly using Xerces 1.4.4. > > -Mark Diggory > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
