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

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

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

OK, as I said, I will try to look at our classloader. But I can confirm 
that the problem that occurs with XMLC 2.3-2 does NOT occur with XMLC 
2.3-1 under EXACTLY the SAME conditions.
As a sample, this time I used the simplest "calculator" application from 
Enhydra Demos package. This sample uses only XMLC and Enhydra Framework 
classes (no database where we use our product DODS, and then JOTM and 
other JTA support libraries).

I deployed "calculator" application under pure Tomcat 6.0-29, JDK 
1.6.0_23 x64, Win7 x64.
It works normally. Then I first replaced xercesImpl, xml-apis and 
nekohtml JAR files with the newer versions from XMLC 2.3-2. It still 
worked normally.
After I finally replaced xmlc.jar (2.3-1) with xmlc-all-runtime.jar, 
removed gnu-regexp.jar and introduced jregex.jar, I get the 1st 
described problem with not being able to find the resource from the JAR 
file:

java.io.FileNotFoundException: 
d:\apache-tomcat-6.0.29\webapps\calculator\WEB-INF\lib\calculator.jarcalculator\presentation\CalculatorHTML.xmlc 
(The system cannot find the path specified)

You can download a set of Enhydra Demo applications (version 8.4-1) for 
pure Tomcat from:

https://docs.google.com/leaf?id=0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=name&layout=list&pid=0B9ZAe6ftekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=18

(If necessary, you can find the source code of Enhydra Demos (TDA), 
Enhydra Framework (TAF), Enhydra DODS (TRO) at:
https://docs.google.com/leaf?id=0B9ZAe6ftekYJNTc0OWM2NzctNzM3MS00YmNjLTkyMTctZjg0ZWUxZWI2YWQw&;hl=en
but to reproduce the problem, downloading the 1st link is enough)

There are many applications based on XMLC included in the ZIP file from 
the 1st link above, ready to be deployed on pure Tomcat.
As the simplest one for testing you can take "calculator.war" I used 
this time.

After I provide a "patch/workaround" for this problem of finding 
resource in the JAR file, the problem disappears.

When I moved all the JAR files except the application JAR file 
(calculator.jar) to the common/shared class-loader (Tomcat's lib 
folder), this time I do NOT have the 2nd problem I described...so that 
might be my mistake during previous tests. The 2nd problem also does NOT 
appear with "discRack" application either. So I assume the 
"patch/workaround" somehow solves all the problems.

Since the ONLY difference with the deployment of this sample 
XMLC/Enhydra Framework/DODS applications is the version of XMLC, can you 
please look at that samples yourself, and confirm the issue.

Greetings,
Sasa.


On 26-Mar-11 20:14, Jacob Kjome wrote:
> The thing is, XMLC doesn't create the URL object that provides the path to the
> resource; the classloader does.  That goes for both XMLC 2.3.1 and 2.3.2.  I can't
> explain why behavior would be different for you between the two versions?  Of
> course, I can't replicate your findings in the first place, so I'm at a loss.
>
> One thing that is a red flag for me is the path you provided...
>
> "d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRack.jardiscRack*\presentation\ErrorHTML.xmlc"
>
> That isn't even a valid URL.  There's no "file:/" and all the slashes are
> backward.  This looks to me like a custom classloader bug.  Again, XMLC doesn't
> generate the URL, the classloader does.
>
> When you say that "it works under 2.3.1", are you sure you tested 2.3.1 with the
> same version of the server you are using to test 2.3.2?  That is, when you tested
> 2.3.1, was the server an older version than what you are using with 2.3.2?  If so,
> please reduce the number of extraneous variables by testing with the older server
> version (the one known to work) and just switching out the 2.3.1 libraries with
> the 2.3.2 libraries.  Do you get better results?
>
> If you can send me a minimal webapp (able to run under Tomcat standalone) with
> explicit instructions on how to replicate the problem, then I'll test it myself
> and let you know the results.
>
> BTW, here's how XMLCContext loads up the deferred parsing factory...
>
> XMLCDeferredParsingFactory newFactory
> 		= new XMLCDeferredParsingFactory(loader,
> Thread.currentThread().getContextClassLoader(), logger);
>
>
> First, notice that the classloader is set up as the thread context class loader of
> the application.  This is the reason why the XMLC Tomcat demo works no matter
> where the XMLC libraries are located in relation to the jar containing the
> templates.  When templates are in the parent classloader, the webapp (child)
> classloader can always see that, so they load just fine.  And when the templates
> are in the webapp classloader while the XMLC libraries are in the parent, XMLC can
> see down to the child classloader because it has a reference to the child
> classloader via the thread context classloader.
>
> Clearly the "(MultiClassLoader) presentationManager.getAppClassLoader()" doesn't
> have a reference to the thread context classloader, otherwise you would not run
> into the issues you have of not finding the templates in certain situations.
>
>
> Second, you can customize the loading of resources by using a custom
> DocumentLoader/ResourceLoader combo.  See the ValidatingDocumentLoader example in
> the Tomcat demo....
>
> http://websvn.ow2.org/filedetails.php?repname=xmlc&path=%2Ftags%2FXMLC_2_3_2%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FValidatingDocumentLoader.java
>
> This one extends ServletDocumentLoaderImpl, but if you don't care about loading
> resources from the servlet context, then you can just extend DocumentLoaderImpl.
> Attached is a sample you can use.  Instead of using
> StandardDocumentLoader.getInstance() in the following...
>
> xmlcFactory = new XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
>
> (MultiClassLoader)presentationManager.getAppClassLoader(),
>                              new EnhydraXMLCLogger(logChannel));
>
> ...use...
>
> xmlcFactory = new XMLCDeferredParsingFactory(new CustomDocumentLoader(),
>
> (MultiClassLoader)presentationManager.getAppClassLoader(),
>                              new EnhydraXMLCLogger(logChannel));
>
> ...and if you want to be able to load resources no matter where they exist in the
> classloader hierarchy relative to where XMLC libraries exist in the hierarchy use...
>
> xmlcFactory = new XMLCDeferredParsingFactory(new CustomDocumentLoader(),
>
> Thread.currentThread().getContextClassLoader(),
>                   new EnhydraXMLCLogger(logChannel));
>
> With the custom document/resource loader, you can change the behavior of resource
> loading without modifying the internals of XMLC at all.  This feature is new to
> XMLC-2.3.2.  However, remember that besides the added plugability provided by
> XMLC-2.3.2, ultimately, XMLC 2.3.1 and 2.3.2 don't do anything different to load
> resources from the classloader.  They both use
> classLoader.getResource("some/path/to/resoruce.html").  If that provides a URL
> producing an invalid path, that's a bug in the classloader, not XMLC.
>
>
> Jake
>
> On 3/25/2011 9:14 AM, Sasa Bojanic wrote:
>> 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.
>>>>>>>>


------------=_1301263014-30467-16017
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

------------=_1301263014-30467-16017--