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

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

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

See comments inline below...

On Mon, 28 Mar 2011 14:35:27 +0200
=A0Sasa Bojanic <[email protected]> wrote:
> Jake, first of all, thanks a lot for your effort!
>=20

No problem.=A0 I any changes I made are breaking applications, I want to =
make=20
sure they get corrected, or at least explained, properly.

> ...here is the followup:
>=20
> 1) I think there is a general problem in XMLC when implementing=20
>CustomDocumentLoader/CustomResourceLoader.
> Hence, the JAVA classes generated based on HTML template always use=20
>StandardDocumentLoader.

I'm not sure I understand how this is a "general problem" with=20
document/resource loaders.=A0 Keep in mind, they are resource location ge=
neric,=20
i.e., they are meant to make resource loading plugable, allowing loading =
from=20
contexts not possible prior to XMLC 2.3.2, such as the servlet context...=
 or=20
even a database.=A0 Loading from a class loader is merely one option, alb=
eit a=20
built-in default one as it has been available (along with loading from=20
configured resource directories) since the original XMLC 2.2 release.=A0 =
The=20
custom one I created for you is a minimal implementation that simply over=
rides=20
the way URLs are obtained from the class loader in the default resource l=
oader=20
implementation.

In my view, this is clearly a class loader bug.=A0 If the class loader ca=
n=20
actually see the resource and provide a URL, then that URL ought to be a =
valid=20
one.=A0 That Tomcat's StandardClassLoader is returning an invalid URL is=20
absolutely a bug that should be reported to, and corrected by, the Tomcat=
=20
team.=A0 Supplying the thread context class loader to the=20
XMLCDeferredParsingFactory constructor is the obvious workaround.=A0 But =
it is a=20
workaround only made necessary by a class loader bug.

That said, I recommend using the thread context class loader regardless o=
f=20
this particular class loader bug, as it provides the added benefit of all=
owing=20
XMLC libraries in the server lib to be able to see classes and resources =
in a=20
child classloader (e.g, the WebappClassLoader).

> Don't know if this can be somehow configured to specify the custom one?=
=20
>options.xmlc?
>=20

I really view this as outside the scope of XMLC configuration.=A0 That=20
configuration is focused on template configuration, not how they are load=
ed.=A0=20
Besides, the resource loader is used to load options.xmlc.=A0 It's a chic=
ken/egg=20
problem.=A0 Application code has complete control over how the=20
XMLCDeferredParsingFactory is instantiated, so it is application code whe=
re=20
this should be addressed.

XMLCContext, if you so choose to use it, provides for various servlet con=
text=20
parameters that you can configure in web.xml to specify various things,=20
including document loaders.=A0 And it **ALWAYS** instantiates the=20
XMLCDeferredParsingFactory using the thread context class loader.=A0 See.=
...

http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%2Ftrunk%2Fxm=
lc%2Fexamples%2Ftomcat%2Fres%2Fwebapps%2Fxmlc%2FWEB-INF%2Fweb.xml.in

http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%2Ftrunk%2Fxm=
lc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FPreview.java


All you need to do to access it is...

XMLCContext context =3D XMLCContext.getContext(servletObj);
...or...
XMLCContext context =3D XMLCContext.getContext(servletContextObj);

...and then...
XMLCDeferredParsingFactory dpFactory =3D=20
context.getXMLCDeferredParsingFactory();


If you use this, your applications will be more configurable and never ru=
n=20
into invalid URLs again.


> 2) Maybe it makes sense to implement the following patch to XMLC's=20
>ResourceLoaderImpl:
>=20
>=A0=A0=A0=A0 protected URL getPathURLFromClasspath(final String candidat=
ePath) {
>=A0=A0=A0=A0=A0=A0=A0=A0URL url =3D=20
>Thread.currentThread().getContextClassLoader().getResource(candidatePath=
);
>=A0=A0=A0=A0=A0=A0=A0=A0if (url=3D=3Dnull) {
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 url =3D fFactory.getPathURLFromClasspath(=
candidatePath);
>=A0=A0=A0=A0=A0=A0=A0=A0}
>=A0=A0=A0=A0=A0=A0=A0=A0return url;
>=A0=A0=A0=A0}
>=20

Actually, it would be the thread context classloader that might be null, =
in=20
the case that the code is not running under a JEE server that sets it.=A0=
 That=20
said, it's an option to consider, e.g.,....

=A0=A0=A0 protected URL getPathURLFromClasspath(final String candidatePat=
h) {
=A0=A0=A0=A0=A0=A0=A0 ClassLoader loader =3D Thread.currentThread().getCo=
ntextClassLoader();
=A0=A0=A0=A0=A0=A0=A0 if (loader !=3D null) {
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return loader..getResource(candidatePat=
h);
=A0=A0=A0=A0=A0=A0=A0 }
=A0=A0=A0=A0=A0=A0=A0 return fFactory.getPathURLFromClasspath(candidatePa=
th);
=A0=A0=A0 }

But while this might transparently resolve your issue, it takes away the=20
ability of the user to determine the class loader to use, which they can=20
currently specify by supplying their class loader of choice to the=20
XMLCDeferredParsingFactory constructor.=A0 For this reason, I hesitate to=
=20
implement this option.


> 3) I found the place where we can patch Enhydra's MultiClassLoader (sim=
ilar=20
>way as the patch provided for XMLCDeferredParsingFactory), so that it re=
turns=20
>the "right" resource path in the case of JAR files, so actually from our=
=20
>side, there is no need for the modification mentioned above.

I take it your class loader wraps Tomcat's StandardClassLoader (when runn=
ing=20
under Tomcat, that is)?=A0 Maybe you should have it wrap the thread conte=
xt=20
class loader instead?=A0 That way, you avoid the StandardClassLoader's=20
buggyness.=A0 In any case, there's no good reason for any class loader to=
 return=20
invalid URLs.=A0 Again, I urge you to report this issue to the Tomcat dev=
elopers=20
so this issue can be properly fixed for everyone using Tomcat's=20
StandardClassLoader.

>=20
> 4) When implementing either the modification on ResourceLoaderImpl or=20
>changing MultiClassLoader, calculator and discRack applications are work=
ing=20
>normally. However, the projectManagement application is working only=20
>"partially"...maybe it is a completely new problem there, or this is the=
=20
>similar one but somehow hidden and not so obvious to determine (just to=20
>mention that application works normally under EXACTLY THE SAME condition=
s=20
>under XMLC2.3-1).
> The start page of projectManagement applications is generated smoothly,=
 when=20
>you log in as admin/enhydra, the next page is also OK.
> However, when you click on the link "Employee" or "Customer", the follo=
wing=20
>exception is thrown:
>=20

This is a completely distinct problem.=A0 This is either an issue with th=
e=20
LazyDOM or, possibly with Xerces itself.=A0 Did you try downgrading to th=
e=20
version of xercesImpl and xml-apis that came with XMLC-2.3.1?=A0 Please t=
ry that=20
first.=A0 If you still get an error, let me know.=A0 I think there was a =
change to=20
the lazydom for XMLC 2.3.2 (some bug fix).=A0 I can't recall exactly what=
 it=20
was, though.=A0 It's possible I introduced a regression.=A0 Only more tes=
ting will=20
tell.

BTW, is the "projectManagement" application runnable under Tomcat-Standal=
one=20
or does it require Enhydra server?

> org.w3c.dom.DOMException: NOT_FOUND_ERR: An attempt is made to referenc=
e a=20
>node in a context where it does not exist.
>=A0=A0=A0=A0=A0=A0=A0=A0 at org.apache.xerces.dom.ParentNode.internalRem=
oveChild(Unknown=20
>Source)
>=A0=A0=A0=A0=A0=A0=A0=A0 at org.apache.xerces.dom.ParentNode.removeChild=
(Unknown Source)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.enhydra.xml.lazydom.LazyElementNoNS.removeChild(LazyElementNoNS.java=
:338)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>projectmanagement.presentation.employees.Administering.handleDefault(Adm=
inistering.java:80)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>projectmanagement.presentation.BasePO.handleEvent(BasePO.java:282)
>=A0=A0=A0=A0=A0=A0=A0=A0 at projectmanagement.presentation.BasePO.run(Ba=
sePO.java:156)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>com.lutris.appserver.server.httpPresentation.HttpPresentationManager.run=
PresentationObj(Unknown=20
>Source)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>com.lutris.appserver.server.httpPresentation.HttpPresentationManager.Run=
(Unknown=20
>Source)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationSer=
vlet.serviceDirect(HttpPresentationServlet.java:697)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationSer=
vlet.service(HttpPresentationServlet.java:822)
>=A0=A0=A0=A0=A0=A0=A0=A0 at javax.servlet.http.HttpServlet.service(HttpS=
ervlet.java:717)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica=
tionFilterChain.java:290)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt=
erChain.java:206)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv=
e.java:233)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv=
e.java:191)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java=
:127)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java=
:102)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.=
java:109)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:2=
98)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.j=
ava:861)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.proce=
ss(Http11AprProtocol.java:579)
>=A0=A0=A0=A0=A0=A0=A0=A0 at=20
>org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)
>=A0=A0=A0=A0=A0=A0=A0=A0 at java.lang.Thread.run(Thread.java:662)
>=20
>=20
> (I just modified a little bit original sources to print the stack trace=
 of=20
>the exception).
>=20
>=A0=A0=A0=A0=A0=A0 table.removeChild(page.getElementTemplateRow());
>=20
> The strange is that such exception does not happen when accessing=20
>Project/Pay Rate/Worksheet links, and the code for this pages is=20
>similar...removal of table template row happens.
>=20
> Can you give me some leads here?
>=20

See above for answers.

> Greetings,
> Sasa.
>=20


Jake

>=20
> On 28-Mar-11 07:11, Jacob Kjome wrote:
>> I tried out your calculator.war example and was able to replicate the=20
>>problem.
>> I've also tracked down the cause.=A0=A0It turns out that while XMLC 2.=
3.1 and=20
>>2.3.2
>> still do essentially the same thing, there's a nuance in how source fi=
le=20
>>URLs are
>> created.=A0=A0In XMLC 2.3.1, the classloader used to obtain the URL is=
 the same=20
>>one
>> that loaded the XMLC class file.=A0=A0In XMLC 2.3.2, it's the one prov=
ided to=20
>>the
>> XMLCDeferredParsingFactory constructor.
>>
>> Now, in the Tomcat demo application, this turns out to be the same=20
>>classloader, as
>> XMLCContext provides "Thread.currentThread().getContextClassLoader()" =
to the
>> XMLCDeferredParsingFactory constructor and, of course, this ends up be=
ing=20
>>the
>> WebappClassLoader as it's a thread from the current application that i=
s=20
>>loading
>> all the classes and the server sets this as the thread context class l=
oader=20
>>for us.
>>
>> As it turns out, when URLs are created from the WebappClassLoader,
>> loader.toString(), or loader.toExternalForm(), produces a valid JAR UR=
L,=20
>>such as...
>>
>> jar:file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/WEB-I=
NF/lib/calculator.jar!/calculator/presentation/Calculator.html
>>
>> However, in the calculator application, the classloader provided to th=
e
>> XMLCDeferredParsingFactory constructor is actually the parent classlod=
er of=20
>>the
>> WebappClassLoader and, under Tomcat Standalone, an instance of
>> "org.apache.catalina.loader.StandardClassLoader".
>>
>> As it turns out, when URLs are created from the StandardClassLoader,
>> loader.toString(), or loader.toExternalForm(), produces an invalid JAR=
 URL,=20
>>such as...
>>
>> file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/WEB-INF/l=
ib/calculator.jarcalculator/presentation/Calculator.html
>>
>>
>> This subtle change in behavior was unforeseen and you are the first to=
=20
>>report it.
>>=A0=A0 I never encountered it in my testing because, as mentioned previ=
ously, I=20
>>always
>> use the thread context class loader.=A0=A0Personally, I think it's a b=
ug in=20
>>Tomcat, as
>> it shouldn't matter what kind of class loader it is.=A0=A0All class lo=
aders=20
>>ought to
>> be able to generate valid jar URLs.=A0=A0I encourage you to report thi=
s to the=20
>>Tomcat
>> development team!
>>
>> At this point, there's no going back to the way XMLC 2.3.1 loaded URLs=
=20
>>because of
>> significant design changes.=A0=A0The point at which URLs are now loade=
d provides=20
>>no
>> access to the XMLC class file and, therefore, no way to obtain the=20
>>classloader
>> that loaded the XMLC class file... that is, unless XMLC always uses th=
e=20
>>thread
>> context classloader to load resources (more on that below).=A0=A0Anywa=
y, here=20
>>are the
>> obvious fixes in my order of preference...
>>
>> 1.=A0=A0Always pass "Thread.currentThread().getContextClassLoader()" t=
o the
>> XMLCDeferredParsingFactory constructor.=A0=A0This resolves all issues,=
 end of=20
>>story.
>>
>> 2.=A0=A0If #1 is not possible/desirable, then you can implement your o=
wn custom
>> document/resource loader, similar to what I attached to my last email =
(see=20
>>the new
>> version attached to this email); the only difference being the method =
to=20
>>override
>> now looks like...
>>
>>=A0=A0=A0=A0=A0=A0protected URL getPathURLFromClasspath(final String ca=
ndidatePath) {
>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return
>> Thread.currentThread().getContextClassLoader().getResource(candidatePa=
th);
>>=A0=A0=A0=A0=A0=A0}
>>
>> 3.=A0=A0Change XMLC's XMLCDeferredParsingFactory.getPathURLFromClasspa=
th(String)
>> method to use the thread context classloader.=A0=A0While this is an op=
tion, it's=20
>>not a
>> very good one because the thread context class loader may not always b=
e the=20
>>right
>> choice.=A0=A0While it generally is the right choice 99.99999% of the t=
ime in a=20
>>JEE
>> environment, XMLC is not always used in a server environment.=A0=A0And=
 there's=20
>>always
>> going to be that edge case where, even in a server environment it's no=
t=20
>>desirable.
>>=A0=A0 And, of course, that's where option #1 really shines.=A0=A0You g=
et to choose=20
>>which
>> classloader to use so XMLC doesn't have to guess.
>>
>> 4.=A0=A0If you can think of a better idea, let me know.=A0=A0I'm highl=
y resistant to=20
>>#3.
>> I realize the change in behavior is inconvenient (and most likely a To=
mcat=20
>>bug
>> anyway), but it's a simple change on the user's part and can be done a=
s part=20
>>of
>> the upgrade from 2.3.1 to 2.3.2.=A0=A0Besides, the design changes that=
=20
>>introduced this
>> [easily-worked-around] situation make XMLC far more flexible in regard=
 to=20
>>resource
>> loading than it was before.=A0=A0I think the benefits outweigh the cos=
ts.
>>
>>
>> Thoughts?
>>
>> Jake
>>
>> On 3/27/2011 3:56 PM, Sasa Bojanic wrote:
>>> OK, as I said, I will try to look at our classloader. But I can confi=
rm
>>> 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 f=
rom
>>> Enhydra Demos package. This sample uses only XMLC and Enhydra Framewo=
rk
>>> 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 J=
AR
>>> file:
>>>
>>> java.io.FileNotFoundException:
>>> d:\apache-tomcat-6.0.29\webapps\calculator\WEB-INF\lib\calculator.jar=
calculator\presentation\CalculatorHTML.xmlc
>>> (The system cannot find the path specified)
>>>
>>> You can download a set of Enhydra Demo applications (version 8.4-1) f=
or
>>> pure Tomcat from:
>>>
>>> https://docs.google.com/leaf?id=3D0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00MD=
U4LWIzNWEtYzhiMjBlMzZjYTZj&sort=3Dname&layout=3Dlist&pid=3D0B9ZAe6ftekYJN=
WQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=3D18
>>>
>>>
>>> (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=3D0B9ZAe6ftekYJNTc0OWM2NzctNzM3MS00Ym=
NjLTkyMTctZjg0ZWUxZWI2YWQw&;hl=3Den
>>>
>>> but to reproduce the problem, downloading the 1st link is enough)
>>>
>>> There are many applications based on XMLC included in the ZIP file fr=
om
>>> 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 tha=
t
>>> 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.=A0=A0That goes for both XMLC 2.3.1 a=
nd
>>>> 2.3.2.=A0=A0I can't
>>>> explain why behavior would be different for you between the two
>>>> versions?=A0=A0Of
>>>> course, I can't replicate your findings in the first place, so I'm a=
t
>>>> 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.jard=
iscRack*\presentation\ErrorHTML.xmlc"
>>>>
>>>>
>>>> That isn't even a valid URL.=A0=A0There's no "file:/" and all the sl=
ashes are
>>>> backward.=A0=A0This looks to me like a custom classloader bug.=A0=A0=
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?=A0=A0That is=
, when
>>>> you tested
>>>> 2.3.1, was the server an older version than what you are using with
>>>> 2.3.2?=A0=A0If 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.=A0=A0Do 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 tes=
t
>>>> it myself
>>>> and let you know the results.
>>>>
>>>> BTW, here's how XMLCContext loads up the deferred parsing factory...
>>>>
>>>> XMLCDeferredParsingFactory newFactory
>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=3D new XMLCDeferredParsingFactory(load=
er,
>>>> Thread.currentThread().getContextClassLoader(), logger);
>>>>
>>>>
>>>> First, notice that the classloader is set up as the thread context
>>>> class loader of
>>>> the application.=A0=A0This is the reason why the XMLC Tomcat demo wo=
rks no
>>>> matter
>>>> where the XMLC libraries are located in relation to the jar containi=
ng
>>>> the
>>>> templates.=A0=A0When templates are in the parent classloader, the we=
bapp
>>>> (child)
>>>> classloader can always see that, so they load just fine.=A0=A0And wh=
en 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.=A0=A0See the ValidatingDocument=
Loader
>>>> example in
>>>> the Tomcat demo....
>>>>
>>>> http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%2Ftags%=
2FXMLC_2_3_2%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FValidatingD=
ocumentLoader.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.=A0=A0Instead of using
>>>> StandardDocumentLoader.getInstance() in the following...
>>>>
>>>> xmlcFactory =3D new
>>>> XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
>>>>
>>>> (MultiClassLoader)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 new EnhydraXMLCLogger(logChannel));
>>>>
>>>> ...use...
>>>>
>>>> xmlcFactory =3D new XMLCDeferredParsingFactory(new CustomDocumentLoa=
der(),
>>>>
>>>> (MultiClassLoader)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 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 =3D new XMLCDeferredParsingFactory(new CustomDocumentLoa=
der(),
>>>>
>>>> Thread.currentThread().getContextClassLoader(),
>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0new Enhyd=
raXMLCLogger(logChannel));
>>>>
>>>> With the custom document/resource loader, you can change the behavio=
r
>>>> of resource
>>>> loading without modifying the internals of XMLC at all.=A0=A0This fe=
ature
>>>> is new to
>>>> XMLC-2.3.2.=A0=A0However, remember that besides the added plugabilit=
y
>>>> 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.=A0=A0They both use
>>>> classLoader.getResource("some/path/to/resoruce.html").=A0=A0If 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 EVERYTHIN=
G
>>>>> WORKS PERFECTLY with XMLC 2.3-1. We don't have a problem with resou=
rce
>>>>> 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 oppo=
sed
>>>>>> 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.=A0=A0But this=
 is
>>>>>> really not XMLC's fault.=A0=A0The classloader's getResource() meth=
od is
>>>>>> returning an invalid path.=A0=A0Other 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 wi=
th
>>>>>> XMLC's core, which I will send in a separate email later today).=A0=
=A0As I
>>>>>> mentioned, it works perfectly well on my system.
>>>>>>
>>>>>> You have, potentially, at least 3 platform differences.=A0=A0The f=
irst is
>>>>>> Win7 x64, where I've only tested on WinXP x32.=A0=A0You may also b=
e using
>>>>>> 64 bit Java, though you'd have to verify that.=A0=A0And you are ru=
nning
>>>>>> under Enhydra, with some "MultiClassLoader" classloader
>>>>>> implementation.=A0=A0Somewhere in these differences lies a bug tha=
t is not
>>>>>> the fault of XMLC.
>>>>>>
>>>>>> I would start first with the "MultiClasLoader" and see whether the=
re
>>>>>> is a bug in its getResource() method that returns URL's with inval=
id
>>>>>> paths when resources are looked up in jar files.=A0=A0Second, I'd =
check if
>>>>>> there's a bug in the JDK you are using (maybe the 64 bit version h=
as a
>>>>>> bug where the 32 bit version I use does not?).=A0=A0Third, 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
>>>>>>=A0=A0=A0=A0Sasa Bojanic<[email protected]>=A0=A0 wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> from what I can see in Enhydra code, XMLCDeferredParsingFactory i=
s
>>>>>>> obtained by calling its constructor:
>>>>>>>
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0xmlcFactory =3D new
>>>>>>> XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
>>>>>>>
>>>>>>> (MultiClassLoader) 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=A0=A0=A0 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 folde=
r.
>>>>>>>
>>>>>>> If you notice, the XMLC is reporting to search for:
>>>>>>>
>>>>>>> d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRack.ja=
rdiscRack*\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.=A0=A0I 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 m=
ade
>>>>>>>> sure to rename
>>>>>>>> the resource dirs so files located there could not be found.=A0=A0=
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.=A0=A0I pla=
ced the
>>>>>>>> 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), which came
>>>>>>>> up fine.=A0=A0I took a look at the log to see how the file was l=
oaded...
>>>>>>>>
>>>>>>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcome.htm=
l
>>>>>>>> from source URL
>>>>>>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/to=
mcat/build/webapps/xmlc/WEB-INF/lib/xmlc-templates.jar!/demo/Welcome_fr.h=
tml
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ...so, clearly it is being loaded via the classloader... and wor=
king
>>>>>>>> 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.=A0=A0It looks like...
>>>>>>>>
>>>>>>>> common.loader=3D${catalina.base}/shared,${catalina.base}/shared/=
*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar,${catalina.ho=
me}/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.=A0=A0Again I tried loading the Welcome.html page an=
d,
>>>>>>>> again, it came up
>>>>>>>> fine.=A0=A0I looked at the log and the INFO message was the same=
 as
>>>>>>>> above.=A0=A0I then
>>>>>>>> moved the templates jar file to the ${catalina.base}/shared
>>>>>>>> directory and tried it
>>>>>>>> again.=A0=A0The page came up fine and the INFO message looked li=
ke...
>>>>>>>>
>>>>>>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcome.htm=
l
>>>>>>>> from source URL
>>>>>>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/to=
mcat/build/shared/xmlc-templates.jar!/demo/Welcome_fr.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not sure what to tell you?=A0=A0It all works fine for me.=A0=
=A0Note
>>>>>>>> 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 XMLCDeferredParsingFac=
tory.
>>>>>>>>
>>>>>>>>
>>>>>>>> At this point, I can only say that it works for me.=A0=A0Maybe t=
he it's
>>>>>>>> platform
>>>>>>>> differences that are causing issues?=A0=A0What OS and version of=
 Java do
>>>>>>>> you use?
>>>>>>>> What does the original "jar:" URL look like when you run it (pri=
or
>>>>>>>> to having to
>>>>>>>> muck with it to get it to work in your environment)?=A0=A0And pl=
ease 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 t=
o
>>>>>>>>> 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.=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 Xerc=
es
>>>>>>>>>> does
>>>>>>>>>> so.=A0=A0Plus it makes for easy testing because JDK1.3 doesn't=
 add
>>>>>>>>>> any of
>>>>>>>>>> its own XML libraries.=A0=A0It's easy to dictate the version w=
ithout
>>>>>>>>>> getting buggy JDK1.4 XML behavior.=A0=A0But I think most of th=
e
>>>>>>>>>> world 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 t=
o 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=A0=A0=A0=A0Sasa Bojanic<[email protected]>=A0=A0=A0=A0wr=
ote:
>>>>>>>>>>> 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 T=
omcat
>>>>>>>>>>> 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 loa=
d
>>>>>>>>>>> them).
>>>>>>>>>>> In this case, XMLC can't load resources (*.html and *.xmlc fi=
les)
>>>>>>>>>>> from JAR file. When resources are not in the JAR file but unp=
acked
>>>>>>>>>>> into WEB-INF\classes folder everything works.
>>>>>>>>>>>
>>>>>>>>>>> After "patching" the method getPathURLFromClasspath() from
>>>>>>>>>>> XMLCDeferredParsingFactory to add:
>>>>>>>>>>>
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (srcURL !=3D null&&
>>>>>>>>>>> srcURL.toString().indexOf(".jar")>=3D 0) {
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0try {
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 S=
tring mdurl =3D srcURL.toString();
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 s=
rcURL =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=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=A0=A0=A0=A0+
>>>>>>>>>>> mdurl.substring(mdurl.indexOf(".jar") + 4));
>>>>>>>>>>>=A0=A0=A0=A0=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=A0=A0=A0=A0=A0=A0}
>>>>>>>>>>>
>>>>>>>>>>> after the line:
>>>>>>>>>>>
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0URL srcURL =3D fDynamicCla=
ssLoader.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 c=
an'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


------------=_1301342648-30467-16072
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

------------=_1301342648-30467-16072--