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

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

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

Hi Jake,

it works perfectly, thanks a lot!

Do you plan to have another release or this will wait for some time?

Greetings,
Sasa.


On 11-Apr-11 06:04, Jacob Kjome wrote:
> 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.


------------=_1302549907-30467-16974
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

------------=_1302549907-30467-16974--