Hi, I'm not keen on replacing the existing xsl used to generate the tld with one that generates a .tld that's not easily readable. A readable expanded TLD is very useful. As you say, a fixed tlddoc release may not be out for a while...
I'm fine with tweaking the existing stylesheet to avoid adding an xmlns entry (as the DTD implicitly adds one anyway, for any app that correctly processes xml documents). I understand you couldn't get this working, though? I'm also fine with using an xsl without formatting to generate a separate .tld file that is *only* used as input to the tlddoc tool. And I'm fine with inserting a new step to take the correctly-generated tld and strip the namespace from it before feeding it to the tld. I'm also looking forward to getting the tlddoc output working again, and am willing to spend some time working with you on it. Unfortunately the next 48 hours are looking pretty busy... Regards, Simon On Fri, 2006-01-13 at 13:27 +0100, Bernd Bohmann wrote: > Hello Simon, > > i have a modified version of xsl that don't add the xmlns attribute. We > can't wait for a new release of the tlddoc lib. > > My suggestion is to replace the xsl with the modified version until the > bug is fixed in the tlddoc lib. > > If you agree I would check in the modified version of xsl. > > Regards > > Bernd > > Simon Kitching schrieb: > > Ok. After all that, I went to file an issue against tlddoc and found one > > already exists for exactly this issue: > > > > https://taglibrarydoc.dev.java.net/issues/show_bug.cgi?id=5 > > > > By the way, dev.java.net *does* require you to *apply for project > > membership* before you're allowed to file a bug. Where's that club with > > the nails in it??? > > > > So I guess the question now is: what shall we do for a workaround? I > > guess it would be possible to take the generated TLD and run it through > > a stylesheet to strip off the namespace, then run tlddoc on the hacked > > version. > > > > Regards, > > > > Simon > > > > On Sat, 2006-01-14 at 00:45 +1300, Simon Kitching wrote: > > > >>Hi, > >> > >>Regarding the "tlddoc" problems. Short version: I'm convinced there's a > >>bug in the tlddoc application; the code is mishandling xml namespaces. > >>MyFaces is right, tlddoc is wrong. Deleting the xmlns declaration from > >>the input tld document just happens to match up with the incorrect > >>assumptions in the code and that cancels out the tlddoc bug, causing the > >>output to actually be generated. > >> > >>I'll go file a bug against tlddoc - if Sun doesn't require me to sign a > >>bunch of legal forms in order to file a bug against code on their "open" > >>site :-( > >> > >>== long explanation follows == > >> > >> > >>Sigh. You need to *log in* to the dev.java.net site to get the data > >>necessary to do an anonymous CVS checkout of the source! Please, someone > >>give Sun's dev.java.net managers a thumping with a clue bat. Sun just > >>don't get open source. > >> > >>For your reference, here's the necessary info: > >> > >>cvs -d :pserver:[EMAIL PROTECTED]:/cvs login > >> > >>followed by > >> > >>cvs -d :pserver:[EMAIL PROTECTED]:/cvs checkout taglibrarydoc > >> > >> > >> > >>Now for the source. Method TLDDocGenerator.generate appears to be the > >>one of most interest here. It calls createTLDSummaryDoc. That method > >>sets up a custom EntityResolver which simply ignores any referenced dtd > >>(well, all external entities of all types, actually): > >><code> > >> documentBuilder.setEntityResolver( > >> new EntityResolver() { > >> public InputSource resolveEntity ( > >> String publicId, String systemId) > >> { > >> return new InputSource(new CharArrayReader(new char[0])); > >> } > >> } > >> ); > >></code> > >> > >>This is also the method responsible for the problem error message: > >><code> > >> if( !taglibNode.getNamespaceURI().equals( Constants.NS_JAVAEE ) > >> && !taglibNode.getNamespaceURI().equals( Constants.NS_J2EE )) { > >> throw new GeneratorException( "Error: " + > >> tagLibrary.getPathDescription() + > >> " does not have xmlns=\"" + Constants.NS_JAVAEE + "\"" ); > >> } > >></code> > >> > >> > >>Method TLDDocGenerator.upgradeTLD is used to "normalise" the input TLD > >>document, by converting anything to the latest JSP taglib version (2.1). > >>When this works correctly, the node *does* end up with the NS_JAVAEE > >>namespace which the above check looks for. However it appears to have a > >>serious mistake when dealing with jsp-version 1.2: > >> // We use getElementsByTagName instead of getElementsByTagNameNS > >> // here since JSP 1.2 TLDs have no namespace. > >> if( root.getElementsByTagName( "jsp-version" ).getLength() > 0 ) { > >> // JSP 1.2 TLD - convert to JSP 2.0 TLD first > >> doc = convertTLD( doc, RESOURCE_PATH + "/tld1_2-tld2_0.xsl" ); > >> root = doc.getDocumentElement(); > >> } > >>However jsp 1.2 <taglib> elements *do* have a namespace. It is: > >>"http://java.sun.com/JSP/TagLibraryDescriptor";. This doesn't have to > >>actually appear in the .tld file, as it's implicitly added by the DTD. > >>But whether it is defined in the xml file inline, or defined implicitly > >>in the DTD, the results are the same (well, except if someone stubs out > >>all access to .DTD files by registering a null EntityResolver!). > >> > >>I'm not sure what this root.getElementsByTagName will do here, when > >>called on an element that *does* have a namespace. Maybe stylesheet > >>tld1_2-tld2_0.xsl gets run, maybe not. If it doesn't, that's definitely > >>going to cause a problem. If it does, then there's still a problem as > >>the stylesheet is trying to match a <taglib> element in no namespace, > >>whereas the input document (correctly) has it in the > >>"http://java.sun.com/JSP/TagLibraryDescriptor"; namespace. > >> > >> > >>Why does it work if the xmlns is deleted from the input tld? Well, this > >>wouldn't have any effect if tlddoc correctly processed referenced DTD > >>files, as the xmlns declaration would just be reinserted by the DTD. > >>However because they stub out all DTDs by using a stub EntityResolver, > >>the input document's <taglib> element is interpreted as being in "no > >>namespace" which is what their code/stylesheet incorrectly assumes. > >> > >>Regards, > >> > >>Simon > >> > >> > >> > >> > >> > >> > > > > > > >
