[xmlc] Re: Re: SSI and XMLC

This is a multi-part message in MIME format...

------------=_1302490666-30467-16910
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Sasa,

I've checked in changes to the XMLC trunk that allows for SSI resolution as I had
originally imagined it worked.  So, now SSI loading can be controlled via a custom
(or default) ResourceLoader.

Besides that, even if it can't be found via a ResourceLoader, it falls back to
prior behavior of resolving it relative to the including file.  The logic has been
made much more intelligent and "./" and "../" are now resolved to the
corresponding directory rather than being left, verbatim, in the resulting path.
this means SSI loadig via JarURLConnection should now work!

Please check out and build (ant all-libs) the trunk to try it out.  You will find
a list of the modified/added files here (pay special attention to the new
SSISystemIdResolver class)...

http://websvn.ow2.org/revision.php?repname=xmlc&isdir=1&


Please let me know about your experience with the changes.

Jake

On 4/1/2011 11:04 AM, Jacob Kjome wrote:
> 
> 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.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

------------=_1302490666-30467-16910
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

------------=_1302490666-30467-16910--