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

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

------------=_1301065433-30467-15939
Content-Type: text/plain;charset=iso-8859-1; format="flowed"
Content-Transfer-Encoding: quoted-printable


In this particular case, XMLC can certainly find the file (as opposed to =
the=20
other case where it can't when XMLC libs are in the server lib, at least =
on=20
your system), but the path is messed up.=A0 But this is really not XMLC's=
=20
fault.=A0 The classloader's getResource() method is returning an invalid =
path.=A0=20
Other than tweaking it with your workaround, there's nothing XMLC can (no=
r=20
should) do about that (though there is a way you can work around this wit=
hout=20
messing with XMLC's core, which I will send in a separate email later tod=
ay).=A0=20
As I mentioned, it works perfectly well on my system.

You have, potentially, at least 3 platform differences.=A0 The first is W=
in7=20
x64, where I've only tested on WinXP x32.=A0 You may also be using 64 bit=
 Java,=20
though you'd have to verify that.=A0 And you are running under Enhydra, w=
ith=20
some "MultiClassLoader" classloader implementation.=A0 Somewhere in these=
=20
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=20
in its getResource() method that returns URL's with invalid paths when=20
resources are looked up in jar files.=A0 Second, I'd check if there's a b=
ug in=20
the JDK you are using (maybe the 64 bit version has a bug where the 32 bi=
t=20
version I use does not?).=A0 Third, I guess could be a bug in Win7, thoug=
h I=20
would think the Java platform would be responsible for working around tha=
t=20
given the supposed "platform independence" and all.

Expect another email describing a workaround you can use, without messing=
 with=20
XMLC's core, a bit later when I have access to my development machine.

Jake


On Thu, 24 Mar 2011 22:41:23 +0100
=A0Sasa Bojanic <[email protected]> wrote:
> Hi,
>=20
> from what I can see in Enhydra code, XMLCDeferredParsingFactory is obta=
ined=20
>by calling its constructor:
>=20
>=A0=A0=A0=A0=A0=A0 xmlcFactory =3D new=20
>XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0(MultiClassLoader)=20
>presentationManager.getAppClassLoader(),
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0new=20
>EnhydraXMLCLogger(logChannel));
>=20
>First of all let me show you an error that occurs when XMLC is in the=20
>application classloader. The error is in the attached document...
>=20
> I use Tomcat 6.0.29, Java 1.6_23, Win7 x64, and all the JARs you've=20
>mentioned are in this case in the application's WEB-INF\lib folder.
>=20
> If you notice, the XMLC is reporting to search for:
>=20
> d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRack.jardiscR=
ack*\presentation\ErrorHTML.xmlc
>=20
> When I "patch" XMLC as described before, this scenario works well.
>=20
> Regards,
> Sasa.
>=20
> On 21-Mar-11 00:34, Jacob Kjome wrote:
>> Hi Sasa,
>>
>> I finally made some time to look into the issues you reported.=20
>> Interestingly, I'm
>> not able to reproduce either issue.=A0=A0I used Tomcat-6.0.29 standalo=
ne, as=20
>>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 su=
re to=20
>>rename
>> the resource dirs so files located there could not be found.=A0=A0I al=
so renamed=20
>>the
>> WEB-INF/xmlc directory in the demo app to ensure templates could not b=
e=20
>>loaded via
>> the servlet context (allowed for by the custom
>> ValidatingDocumentLoader.ValidatingResourceLoader class used in the xm=
lc=20
>>tomcat
>> demo), thus could only be loaded via the classloader.=A0=A0I placed th=
e=20
>>templates jar
>> in WEB-INF/lib and ran tomcat.=A0=A0First I tried loading the Welcome.=
html page
>> (french locale, because that's what I had selected in the tomcat demo)=
,=20
>>which came
>> up fine.=A0=A0I took a look at the log to see how the file was loaded.=
..
>>
>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcome.html from=
=20
>>source URL
>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/tomcat/b=
uild/webapps/xmlc/WEB-INF/lib/xmlc-templates.jar!/demo/Welcome_fr.html
>>
>> ...so, clearly it is being loaded via the classloader... and working f=
ine=20
>>for me.
>>
>>
>> To test issue #2, I copied the following jars into=20
>>${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 c=
ommon
>> loader.=A0=A0It looks like...
>>
>> common.loader=3D${catalina.base}/shared,${catalina.base}/shared/*.jar,=
${catalina.home}/shared,${catalina.home}/shared/*.jar,${catalina.home}/li=
b,${catalina.home}/lib/*.jar
>>
>> This would be no different than putting the jars in ${catalina.home}/l=
ib,=20
>>but
>> avoids having to muck with the contents of the stock Tomcat installati=
on.
>>
>> Anyway, I left my jar file containing the XMLC classes and templates i=
n
>> WEB-INF/lib.=A0=A0Again I tried loading the Welcome.html page and, aga=
in, it=20
>>came up
>> fine.=A0=A0I looked at the log and the INFO message was the same as ab=
ove.=A0=A0I=20
>>then
>> moved the templates jar file to the ${catalina.base}/shared directory =
and=20
>>tried it
>> again.=A0=A0The page came up fine and the INFO message looked like...
>>
>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcome.html from=
=20
>>source URL
>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/tomcat/b=
uild/shared/xmlc-templates.jar!/demo/Welcome_fr.html
>>
>>
>> I'm not sure what to tell you?=A0=A0It all works fine for me.=A0=A0Not=
e 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.=A0=A0Maybe the it'=
s platform
>> differences that are causing issues?=A0=A0What OS and version of Java =
do you=20
>>use?
>> What does the original "jar:" URL look like when you run it (prior to =
having=20
>>to
>> muck with it to get it to work in your environment)?=A0=A0And please l=
et me know=20
>>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 o=
ne
>>> 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 t=
he
>>>> next XML release.=A0=A0I 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 doe=
s
>>>> so.=A0=A0Plus it makes for easy testing because JDK1.3 doesn't add a=
ny of
>>>> its own XML libraries.=A0=A0It's easy to dictate the version without
>>>> getting buggy JDK1.4 XML behavior.=A0=A0But I think most of the worl=
d has
>>>> moved on to JDK1.5+, so maybe XMLC should too at some point?
>>>>
>>>> I'll have to test #2.=A0=A0Not sure how quickly I'll be able to get =
to
>>>> this, though.=A0=A0But I'll try and spend some time this week on it.
>>>>
>>>> Jake
>>>>
>>>> On Mon, 07 Mar 2011 13:56:15 +0100
>>>>=A0=A0 Sasa Bojanic<[email protected]>=A0=A0wrote:
>>>>> 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:
>>>>>
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0 if (srcURL !=3D null&&=A0=A0srcURL.toString=
().indexOf(".jar")>=3D 0) {
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 try {
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0String mdurl =3D=
 srcURL.toString();
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0srcURL =3D new=
 URL("jar:"
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 + mdurl.substring(0,
>>>>> mdurl.indexOf(".jar")) + ".jar!/"
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +
>>>>> mdurl.substring(mdurl.indexOf(".jar") + 4));
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 } catch (Exception ex) {
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0 }
>>>>>
>>>>> after the line:
>>>>>
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0 URL srcURL =3D fDynamicClassLoader.getResou=
rce(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\li=
b,
>>>>> 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.
>>>>>
>=20


------------=_1301065433-30467-15939
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

------------=_1301065433-30467-15939--