[xmlc] Re: Re: Re: Re: Re: Re: Issues with XMLC 2.3.2

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

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

Hi,

yes, I'm of course also using 64-bit Java.

I will check about our MultiClassLoader, but the point is EVERYTHING 
WORKS PERFECTLY with XMLC 2.3-1. We don't have a problem with resource 
lookup within the JAR file, and do not have a problem with scenario 
where XMLC is not in the application's classloader.

We are trying to find the reason why we can't switch to XMLC 2.3-2 
seamlessly...and since everything works with XMLC2.3-1 we think it is a 
XMLC issue?

Regards,
Sasa.

On 25-Mar-11 16:03, Jacob Kjome wrote:
>
> In this particular case, XMLC can certainly find the file (as opposed 
> to the other case where it can't when XMLC libs are in the server lib, 
> at least on your system), but the path is messed up.  But this is 
> really not XMLC's fault.  The classloader's getResource() method is 
> returning an invalid path.  Other than tweaking it with your 
> workaround, there's nothing XMLC can (nor should) do about that 
> (though there is a way you can work around this without messing with 
> XMLC's core, which I will send in a separate email later today).  As I 
> mentioned, it works perfectly well on my system.
>
> You have, potentially, at least 3 platform differences.  The first is 
> Win7 x64, where I've only tested on WinXP x32.  You may also be using 
> 64 bit Java, though you'd have to verify that.  And you are running 
> under Enhydra, with some "MultiClassLoader" classloader 
> implementation.  Somewhere in these differences lies a bug that is not 
> the fault of XMLC.
>
> I would start first with the "MultiClasLoader" and see whether there 
> is a bug in its getResource() method that returns URL's with invalid 
> paths when resources are looked up in jar files.  Second, I'd check if 
> there's a bug in the JDK you are using (maybe the 64 bit version has a 
> bug where the 32 bit version I use does not?).  Third, I guess could 
> be a bug in Win7, though I would think the Java platform would be 
> responsible for working around that given the supposed "platform 
> independence" and all.
>
> Expect another email describing a workaround you can use, without 
> messing with XMLC's core, a bit later when I have access to my 
> development machine.
>
> Jake
>
>
> On Thu, 24 Mar 2011 22:41:23 +0100
>  Sasa Bojanic <[email protected]> wrote:
>> Hi,
>>
>> from what I can see in Enhydra code, XMLCDeferredParsingFactory is 
>> obtained by calling its constructor:
>>
>>        xmlcFactory = new 
>> XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
>>                                                     (MultiClassLoader) presentationManager.getAppClassLoader(), 
>>
>>                                                     new 
>> EnhydraXMLCLogger(logChannel));
>>
>> First of all let me show you an error that occurs when XMLC is in the 
>> application classloader. The error is in the attached document...
>>
>> I use Tomcat 6.0.29, Java 1.6_23, Win7 x64, and all the JARs you've 
>> mentioned are in this case in the application's WEB-INF\lib folder.
>>
>> If you notice, the XMLC is reporting to search for:
>>
>> d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRack.jardiscRack*\presentation\ErrorHTML.xmlc 
>>
>>
>> When I "patch" XMLC as described before, this scenario works well.
>>
>> Regards,
>> Sasa.
>>
>> On 21-Mar-11 00:34, Jacob Kjome wrote:
>>> Hi Sasa,
>>>
>>> I finally made some time to look into the issues you reported. 
>>> Interestingly, I'm
>>> not able to reproduce either issue.  I used Tomcat-6.0.29 
>>> standalone, as that's
>>> the version you used (note that I did not try Enhydra).
>>>
>>> To test issue #1, I jar'ed up the classes and markup files and made 
>>> sure to rename
>>> the resource dirs so files located there could not be found.  I also 
>>> renamed the
>>> WEB-INF/xmlc directory in the demo app to ensure templates could not 
>>> be loaded via
>>> the servlet context (allowed for by the custom
>>> ValidatingDocumentLoader.ValidatingResourceLoader class used in the 
>>> xmlc tomcat
>>> demo), thus could only be loaded via the classloader.  I placed the 
>>> templates jar
>>> in WEB-INF/lib and ran tomcat.  First I tried loading the 
>>> Welcome.html page
>>> (french locale, because that's what I had selected in the tomcat 
>>> demo), which came
>>> up fine.  I took a look at the log to see how the file was loaded...
>>>
>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcome.html 
>>> from source URL
>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/tomcat/build/webapps/xmlc/WEB-INF/lib/xmlc-templates.jar!/demo/Welcome_fr.html 
>>>
>>>
>>> ...so, clearly it is being loaded via the classloader... and working 
>>> fine for me.
>>>
>>>
>>> To test issue #2, I copied the following jars into 
>>> ${catalina.base}/shared...
>>>
>>> jregex.jar
>>> nekohtml.jar
>>> resolver.jar
>>> xercesImpl.jar
>>> xml-apis.jar
>>> xmlc-all-runtime.jar
>>>
>>> Note that the Tomcat demo has a modified
>>> ${catalina.base}/conf/catalina.properties, which places the
>>> ${catalina.base}/shared directory, as well as contained jars, in the 
>>> common
>>> loader.  It looks like...
>>>
>>> common.loader=${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar 
>>>
>>>
>>> This would be no different than putting the jars in 
>>> ${catalina.home}/lib, but
>>> avoids having to muck with the contents of the stock Tomcat 
>>> installation.
>>>
>>> Anyway, I left my jar file containing the XMLC classes and templates in
>>> WEB-INF/lib.  Again I tried loading the Welcome.html page and, 
>>> again, it came up
>>> fine.  I looked at the log and the INFO message was the same as 
>>> above.  I then
>>> moved the templates jar file to the ${catalina.base}/shared 
>>> directory and tried it
>>> again.  The page came up fine and the INFO message looked like...
>>>
>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcome.html 
>>> from source URL
>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/tomcat/build/shared/xmlc-templates.jar!/demo/Welcome_fr.html 
>>>
>>>
>>>
>>> I'm not sure what to tell you?  It all works fine for me.  Note that my
>>> environment consists of...
>>>
>>> Windows XP sp3
>>> Java 1.6.0_24
>>> Tomcat-6.0.29 (standalone run from the command line)
>>>
>>>
>>> Note that I use XMLCContext to obtain the XMLCDeferredParsingFactory.
>>>
>>>
>>> At this point, I can only say that it works for me.  Maybe the it's 
>>> platform
>>> differences that are causing issues?  What OS and version of Java do 
>>> you use?
>>> What does the original "jar:" URL look like when you run it (prior 
>>> to having to
>>> muck with it to get it to work in your environment)?  And please let 
>>> me know how
>>> you obtain the XMLCDeferredParsingFactory.
>>>
>>>
>>> Jake
>>>
>>>
>>> On 3/7/2011 1:46 PM, Sasa Bojanic wrote:
>>>> Well, it is not really a patch, but something that made my use case 
>>>> one
>>>> working...I agree nowdays it would be reasonable to move XMLC to 
>>>> JDK1.5
>>>> or even 1.6...
>>>>
>>>> Thanks a lot for the quick response!
>>>>
>>>> Sasa.
>>>>
>>>>
>>>> On 07-Mar-11 17:13, Jacob Kjome wrote:
>>>>> I can look into using your patch for #1 (or something like it) for 
>>>>> the
>>>>> next XML release.  I think the primary issue here is that we've
>>>>> maintained a dependency on JDK1.3, which does not have java.net.URI.
>>>>> I've tried to maintain this minimum dependency as long as Xerces does
>>>>> so.  Plus it makes for easy testing because JDK1.3 doesn't add any of
>>>>> its own XML libraries.  It's easy to dictate the version without
>>>>> getting buggy JDK1.4 XML behavior.  But I think most of the world has
>>>>> moved on to JDK1.5+, so maybe XMLC should too at some point?
>>>>>
>>>>> I'll have to test #2.  Not sure how quickly I'll be able to get to
>>>>> this, though.  But I'll try and spend some time this week on it.
>>>>>
>>>>> Jake
>>>>>
>>>>> On Mon, 07 Mar 2011 13:56:15 +0100
>>>>>    Sasa Bojanic<[email protected]>  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to upgrade our applications that use XMLC 2.3.1 to the
>>>>>> newest XMLC version.
>>>>>> Our applications are deployed both under the Tomcat 6.0.29
>>>>>> application server and Enhydra application server (based on Tomcat
>>>>>> 6.0.29).
>>>>>>
>>>>>> There are two issues I faced:
>>>>>>
>>>>>> 1) when deploying under the Tomcat, XMLC JAR files are placed
>>>>>> together with the application JAR files into application's
>>>>>> WEB-INF\lib folder (so application classloader is used to load 
>>>>>> them).
>>>>>> In this case, XMLC can't load resources (*.html and *.xmlc files)
>>>>>> from JAR file. When resources are not in the JAR file but unpacked
>>>>>> into WEB-INF\classes folder everything works.
>>>>>>
>>>>>> After "patching" the method getPathURLFromClasspath() from
>>>>>> XMLCDeferredParsingFactory to add:
>>>>>>
>>>>>>          if (srcURL != 
>>>>>> null&&  srcURL.toString().indexOf(".jar")>= 0) {
>>>>>>                try {
>>>>>>                   String mdurl = srcURL.toString();
>>>>>>                   srcURL = new URL("jar:"
>>>>>>                                    + mdurl.substring(0,
>>>>>> mdurl.indexOf(".jar")) + ".jar!/"
>>>>>>                                    +
>>>>>> mdurl.substring(mdurl.indexOf(".jar") + 4));
>>>>>>                } catch (Exception ex) {
>>>>>>             }
>>>>>>          }
>>>>>>
>>>>>> after the line:
>>>>>>
>>>>>>          URL srcURL = fDynamicClassLoader.getResource(path);
>>>>>>
>>>>>> it works fine.
>>>>>>
>>>>>> 2) when deploying under Enhydra application server or under Tomcat,
>>>>>> but instead of putting XMLC JAR files into application's 
>>>>>> WEB-INF\lib,
>>>>>> we put it into Tomcat's lib folder, XMLC can't find resources no
>>>>>> matter if resources are inside JAR file or unpacked, and it can't
>>>>>> find it even in the case I put application's JAR file into Tomcat's
>>>>>> lib folder.
>>>>>>
>>>>>> Is it a bug in XMLC? Can somebody help?
>>>>>>
>>>>>> Regards,
>>>>>> Sasa.
>>>>>>
>>
>


------------=_1301066053-30467-15944
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

------------=_1301066053-30467-15944--