[xmlc] Re: Re: Re: Re: Re: Re: Re: SSI and XMLC
Jacob Kjome <[email protected]> Fri, 01 Apr 2011 11:04:43 -0600
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format... ------------=_1301673471-30467-16381 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit After thinking about it later, I suspected my memory might have failed me. I think XMLC just uses the parent markup file's path as a base. Sorry about that. I won't have time to look at this until tonight, though. I think it's still a bug in the JarURLConnection class, but I think XMLC can work around it by pre-resolving the path. Jake On 4/1/2011 12:58 AM, Sasa Bojanic wrote: > I think you are not right this time... > > I logged all the lookups from ResourceLoader.getResource(String[] > candidatePaths), and there is no lookup for SSI paths, only for the path > of HTML that is including SSI. > SSI is processed inside SSIReader code, and does not callback neither to > ResourceLoader nor DocumentLoader. > > What happens in our sample is that during the creation of new instance > of XMLC class LoginHTML, ResourceLoader first searches for Login.html > and then (during loading of meta data) for one of the > Login.xmlc/LoginHTML.xmlc/LoginHTMLImpl.xmlc. After that, a job is > delegated to "Parse" class, then to XercesHTMLDOMParser and > XercesDOMParser, which processes LoginHTML file by delegating it to > APACHE XERCES and NEKOHTML...and at the end it ends up to SSIReader in > XMLC... > > SSIReader gets the information about the JAR file where to search for > SSI and about SSI itself (openSSIInclude method): > includingFileName=jar:file:/D:/apache-tomcat-6.0.29/webapps/airSent/WEB-INF/lib/airSent.jar!/com/lutris/airsent/presentation/customer/Login.html, > fileName=../media/TopBanner.ssi > > I don't know how can I utilize our custom Document/ClassLoader there... > > I've also seen in several places in the code that there is an explicit > call to Thread.currentThread().getContextClassLoader(), and one of the > places is XercesDOMParser.parse() method which is called during > processing SSI...don't know if this is somehow related... > > Greetings, > Sasa. > > On 31-Mar-11 23:34, Jacob Kjome wrote: >> >> Actually, yes you can. That's the whole point of the new resource >> loader concept in XMLC 2.3.2. It's THE central location for ALL >> resource lookups in XMLC. You can verify this yourself by using the >> custom document/resource loader I sent you earlier and logging the >> paths that are requested just before the URL is looked up and >> returned. You will find that the path for the SSI include is looked >> up. After all, there's no parsing a URL before the URL is obtained. >> And the resource loader is what obtains the URL. >> >> So, all you need to do is let the classloader return the URL. Then >> check URL.toExternalForm() (or URL.toString) for the path being both a >> "jar:" URL and having ".." in the path. If so, then manipulate the >> path resolving the ".." bits to the canonical path without "..". >> >> I wonder if Java 1.4+ URI class might do this for you without extra >> manual manipulation? You might want to look into that. You also >> might want to report this as a bug or feature request against >> JarURLConnection to Oracle (I wanted to say Sun). >> >> >> Jake >> >> On Thu, 31 Mar 2011 23:04:41 +0200 >> Sasa Bojanic <[email protected]> wrote: >>> Again... >>> >>> Not sure if having custom DocumentLoader/Classloader can help, since >>> resolving of SSI happens during "parse" of HTML file...I think this >>> should be corrected in SSIReader class, openSSIInclude method...and I >>> doubt we can simply "customize" it from outside XMLC? >>> >>> Sasa. >>> >>> On 31-Mar-11 21:53, Sasa Bojanic wrote: >>>> Yes, when the resource is not within the JAR file (but in the >>>> WEB-INF\classes folder) the paths with "/../" are working fine... >>>> >>>> With your help, we gave up from custom classloader for XMLC, and now >>>> also use non-singleton DocumentLoader instances (implicitly created >>>> by XMLCDefferedParsingFactory). >>>> However, we will consider your suggestions in order to solve this >>>> SSI issue... >>>> >>>> Thanks a lot, >>>> Sasa. >>>> >>>> (since you helped us a lot with thi >>>> On 31-Mar-11 21:40, Jacob Kjome wrote: >>>>> >>>>> I see. That makes more sense, as I don't recall anything having >>>>> specifically to do with SSI loading having changed between XMLC >>>>> 2.3.1 and 2.3.2 (at least nothing that should affect this scenario). >>>>> >>>>> I suspect, ultimately, that this is a deficiency of >>>>> JarURLConnection in dealing with paths containing "/../", though I >>>>> have yet to verify this. I believe this works fine when it's a non >>>>> "jar:" URL path, so I think the problem is specific to >>>>> JarURLConnection. >>>>> >>>>> You could probably work around this either in your custom >>>>> classloader (where, as I recall, you applied the fix for "jar:" >>>>> URLs originally) or in a custom document/resource loader. All >>>>> you'd need to do is re-write the path of the URL to pre-resolve the >>>>> ".." parts changing, for instance, this... >>>>> >>>>> jar:file:/D:/apache-tomcat-6.0.29/webapps/airSent/WEB-INF/lib/airSent.jar!/com/lutris/airsent/presentation/customer/../media/TopBanner.ssi >>>>> >>>>> ...to this... >>>>> >>>>> jar:file:/D:/apache-tomcat-6.0.29/webapps/airSent/WEB-INF/lib/airSent.jar!/com/lutris/airsent/presentation/media/TopBanner.ssi >>>>> >>>>> >>>>> That said, this is probably something that XMLC could take care of >>>>> internally. I would certainly consider this for the next release >>>>> if my assumptions pan out. >>>>> >>>>> >>>>> Jake >>>>> >>>>> On Thu, 31 Mar 2011 21:11:06 +0200 >>>>> Sasa Bojanic <[email protected]> wrote: >>>>>> Sorry...it doesn't work with XMLC 2.3-1 as well... >>>>>> >>>>>> Yes, the com/lutris/airsent/presentation/media/TopBanner.ssi is >>>>>> the right location within the JAR. >>>>>> >>>>>> You can try with the airSent.war from the ZIP file. However, if >>>>>> you use this WAR as it is, everything works well both with >>>>>> XMLC2.3-1 (which is originally inside the WAR) and with XMLC2.3-2 >>>>>> (when you replace the XMLC/GNUREGEXP JAR files). The problem >>>>>> occurs when you pack everything from WEB-INF\classes folder into >>>>>> the JAR file, and then put this JAR file into WEB-INF\lib folder >>>>>> (and this is the change we are introducing in our new release). So >>>>>> the problem was here even in XMLC 2.3-1 but we didn't notice it. >>>>>> >>>>>> Do you think it is an XMLC problem or...? >>>>>> >>>>>> Sasa. >>>>>> >>>>>> On 31-Mar-11 19:44, Jacob Kjome wrote: >>>>>>> >>>>>>> It looks like it's referencing the jar it should exist in, and >>>>>>> clearly it found the markup file including the SSI, so I don't >>>>>>> think this is a classloader issue. >>>>>>> >>>>>>> Does the path seem right to you? That is, does the file in >>>>>>> question exist in the following relative path within the >>>>>>> airSent.jar file?.... >>>>>>> >>>>>>> com/lutris/airsent/presentation/media/TopBanner.ssi >>>>>>> >>>>>>> If you can confirm that, I can try to test things out at home >>>>>>> tonight. I presume this jar is one of those in the zip file >>>>>>> containing all the webapps which can be deployed under Tomcat >>>>>>> Standalone? >>>>>>> >>>>>>> >>>>>>> Jake >>>>>>> >>>>>>> On Thu, 31 Mar 2011 16:31:32 +0200 >>>>>>> Sasa Bojanic <[email protected]> wrote: >>>>>>>> Me again :-) >>>>>>>> >>>>>>>> Just a question...have you changed to XMLC related to Server >>>>>>>> Side Includes from HTML? >>>>>>>> >>>>>>>> The situation is the following: >>>>>>>> >>>>>>>> HTML file (processed by XMLC) includes another HTML file via >>>>>>>> relative path: >>>>>>>> >>>>>>>> <!--#include virtual="../media/TopBanner.ssi"--> >>>>>>>> >>>>>>>> When XMLC parses HTML file, I get the following exception (when >>>>>>>> all the resources are in the JAR file): >>>>>>>> >>>>>>>> java.io.FileNotFoundException: JAR entry >>>>>>>> com/lutris/airsent/presentation/customer/../media/TopBanner.ssi >>>>>>>> not found in >>>>>>>> D:\apache-tomcat-6.0.29\webapps\airSent\WEB-INF\lib\airSent.jar >>>>>>>> at >>>>>>>> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) >>>>>>>> >>>>>>>> at >>>>>>>> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.io.InputSourceOps.openSystemId(InputSourceOps.java:65) >>>>>>>> at >>>>>>>> org.enhydra.xml.io.InputSourceOps.open(InputSourceOps.java:85) >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.misc.SSIParsedStream.readIntoBuffer(SSIParsedStream.java:198) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.misc.SSIParsedStream.<init>(SSIParsedStream.java:159) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.misc.SSIReader.openSSIInclude(SSIReader.java:153) >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.misc.SSIReader.processSSIInclude(SSIReader.java:169) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.misc.SSIReader.processSSIDirective(SSIReader.java:179) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.misc.SSIReader.read(SSIReader.java:228) >>>>>>>> at >>>>>>>> org.cyberneko.html.HTMLScanner$CurrentEntity.load(HTMLScanner.java:1772) >>>>>>>> at >>>>>>>> org.cyberneko.html.HTMLScanner.skipNewlines(HTMLScanner.java:1522) >>>>>>>> at >>>>>>>> org.cyberneko.html.HTMLScanner$ContentScanner.scanCharacters(HTMLScanner.java:2227) >>>>>>>> >>>>>>>> at >>>>>>>> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1964) >>>>>>>> >>>>>>>> at >>>>>>>> org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895) >>>>>>>> at >>>>>>>> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499) >>>>>>>> at >>>>>>>> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452) >>>>>>>> at org.apache.xerces.parsers.XMLParser.parse(Unknown >>>>>>>> Source) >>>>>>>> at org.apache.xerces.parsers.DOMParser.parse(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.parsers.xerces.XercesDOMParser.parse(XercesDOMParser.java:113) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.parsers.xerces.XercesHTMLDOMParser.parse(XercesHTMLDOMParser.java:64) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.compiler.Parse.parse(Parse.java:291) >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.parseDocument(DocumentLoaderImpl.java:405) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getCacheEntry(DocumentLoaderImpl.java:175) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getDocument(DocumentLoaderImpl.java:247) >>>>>>>> >>>>>>>> at >>>>>>>> com.lutris.airsent.presentation.customer.LoginHTML.buildDocument(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> com.lutris.airsent.presentation.customer.LoginHTML.<init>(Unknown Source) >>>>>>>> >>>>>>>> at >>>>>>>> com.lutris.airsent.presentation.customer.LoginHTML.<init>(Unknown Source) >>>>>>>> >>>>>>>> at >>>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>>>>>>> Method) >>>>>>>> at >>>>>>>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>>>>>>> >>>>>>>> at >>>>>>>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>>>>>>> >>>>>>>> at >>>>>>>> java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.createObject(XMLCDeferredParsingFactory.java:160) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.doCreate(XMLCDeferredParsingFactory.java:185) >>>>>>>> >>>>>>>> at >>>>>>>> org.enhydra.xml.xmlc.XMLCStdFactory.create(XMLCStdFactory.java:139) >>>>>>>> at >>>>>>>> com.lutris.airsent.presentation.customer.Login.showPage(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> com.lutris.airsent.presentation.customer.Login.handleDefault(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> com.lutris.airsent.presentation.BasePO.handleEvent(Unknown Source) >>>>>>>> at com.lutris.airsent.presentation.BasePO.run(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> com.lutris.appserver.server.httpPresentation.HttpPresentationManager.runPresentationObj(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> com.lutris.appserver.server.httpPresentation.HttpPresentationManager.Run(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.serviceDirect(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.service(Unknown >>>>>>>> Source) >>>>>>>> at >>>>>>>> javax.servlet.http.HttpServlet.service(HttpServlet.java:717) >>>>>>>> at >>>>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) >>>>>>>> >>>>>>>> at >>>>>>>> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584) >>>>>>>> at java.lang.Thread.run(Thread.java:662) >>>>>>>> org.enhydra.xml.xmlc.XMLCError: Couldn't load XMLC class >>>>>>>> >>>>>>>> >>>>>>>> Just to mention, like always with XMLC2.3-1 it worked...maybe >>>>>>>> because our "magical" classloader...but can't be sure. >>>>>>>> >>>>>>>> Greetings, >>>>>>>> Sasa. >>>>>>> >>>>>> >>>>> >>>> >>> >> > ------------=_1301673471-30467-16381 Content-Type: text/plain; charset="UTF-8"; name="message-footer.txt" Content-Disposition: inline; filename="message-footer.txt" Content-Transfer-Encoding: quoted-printable -- You receive this message as a subscriber of the [email protected] mailing list= . To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=3Dhelp OW2 mailing lists service home page: http://www.ow2.org/wws ------------=_1301673471-30467-16381--