[xmlc] Re: Re: Re: Re: Re: Re: SSI and XMLC

Sasa Bojanic <[email protected]> Fri, 01 Apr 2011 08:58:14 +0200
Newsgroups gmane.comp.java.enhydra.xmlc
Message-ID <[email protected]>
This is a multi-part message in MIME format...

------------=_1301641109-30467-16304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.
>>>>>>
>>>>>
>>>>
>>>
>>
>


------------=_1301641109-30467-16304
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

------------=_1301641109-30467-16304--