jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: Can't deploy Custom Tag Library on Microsoth Windoz
Date Tue, 08 Oct 2002 00:53:00 GMT
> 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:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>


Mime
View raw message