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

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

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


Correct, nothing to report to nekohtml.=A0 Note that your code should alw=
ays be=20
defensive like this.=A0 Never assume parent nodes.=A0 Always look them up=
.

Jake

On Tue, 29 Mar 2011 08:02:09 +0200
=A0Sasa Bojanic <[email protected]> wrote:
> When I change the code as you suggested, the problem disappears.
>=20
> I assume there is nothing to report to NEKOHTML then?
>=20
> Thanks,
> Sasa.
>=20
> On 29-Mar-11 08:51, Jacob Kjome wrote:
>> I suspect nekohtml is manipulating the table in ways you didn't expect=
.=20
>> Check out
>> this from the 1.9.13 release note [1]...
>>
>> "automatically add TBODY around TR nested directly within TABLE"
>>
>> You say your code is...
>>
>> table.removeChild(page.getElementTemplateRow());
>>
>> But if nekohtml is adding a TBODY node around TR, then TR is not a chi=
ld of=20
>>TABLE,
>> but TBODY, which could very well explain the error you are seeing.=A0=A0=
It seems=20
>>to me
>> that safer code would be...
>>
>> page.getElementTemplateRow().getParentNode().removeChild(page.getEleme=
ntTemplateRow());
>>
>>
>> Can you try that and let me know if the issue goes away with nekohtml=20
>>version
>> 1.9.13 or later?
>>
>>
>> [1] http://nekohtml.sourceforge.net/changes.html
>>
>> Jake
>>
>> On 3/29/2011 12:06 AM, Jacob Kjome wrote:
>>> I've narrowed down the DOMException NOT_FOUND_ERR problem to nekohtml=
.=A0=A0When=20
>>>I use
>>> version 1.9.8, which is distributed with XMLC 2.3.1, everything works=
 fine,=20
>>>even
>>> with XMLC 2.3.2.=A0=A0But when I use version 1.9.14, I get the error =
you=20
>>>reported,
>>> even with XMLC 2.3.1.
>>>
>>> I backtracked through the versions of nekohtml to find the latest ver=
sion=20
>>>that
>>> would work.=A0=A0I discovered that version 1.9.12 works fine, but 1.9=
.13 fails.=20
>>> So,
>>> something introduced in 1.9.13 is causing the problem.=A0=A0I'll try =
to do some=20
>>>more
>>> digging this week to figure out what the root cause is.=A0=A0It would=
 be great=20
>>> if you
>>> could do the same.=A0=A0When we can pinpoint the issue, we can report=
 it as a=20
>>>bug in
>>> the nekohtml sourceforge project [1].
>>>
>>>
>>> [1] http://sourceforge.net/projects/nekohtml/
>>>
>>>
>>> Jake
>>>
>>> On 3/28/2011 2:28 PM, Sasa Bojanic wrote:
>>>> My mistake about the "general" problem...now I see that generated XM=
LC
>>>> Java classes have non-default constructor taking DocumentLoader obje=
ct
>>>> as an initialization parameter...sorry.
>>>>
>>>> I still hesitate to contact Tomcat guys since I'm not deep into our
>>>> MultiClassLoader code...so I don't know if there is a bug in-there.
>>>>
>>>> Regarding DOM problem, yes, I tried both XERCES/XML-APIS from XMLC2.=
3-1
>>>> and XMLC2.3-2, and the result is the same.
>>>>
>>>> "projectManagement" application and ALL other applications from the =
ZIP
>>>> file:
>>>> https://docs.google.com/leaf?id=3D0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00M=
DU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=3Dname&layout=3Dlist&pid=3D0B9ZAe6ftekYJ=
NWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=3D18
>>>>
>>>>
>>>> are prepared for Stand-alone Tomcat deployment...
>>>>
>>>> Greetings,
>>>> Sasa.
>>>>
>>>> On 28-Mar-11 22:04, Jacob Kjome wrote:
>>>>> See comments inline below...
>>>>>
>>>>> On Mon, 28 Mar 2011 14:35:27 +0200
>>>>>=A0=A0 Sasa Bojanic<[email protected]>=A0=A0wrote:
>>>>>> Jake, first of all, thanks a lot for your effort!
>>>>>>
>>>>> No problem.=A0=A0I any changes I made are breaking applications, I =
want to
>>>>> make sure they get corrected, or at least explained, properly.
>>>>>
>>>>>> ...here is the followup:
>>>>>>
>>>>>> 1) I think there is a general problem in XMLC when implementing
>>>>>> CustomDocumentLoader/CustomResourceLoader.
>>>>>> Hence, the JAVA classes generated based on HTML template always us=
e
>>>>>> StandardDocumentLoader.
>>>>> I'm not sure I understand how this is a "general problem" with
>>>>> document/resource loaders.=A0=A0Keep in mind, they are resource loc=
ation
>>>>> generic, i.e., they are meant to make resource loading plugable,
>>>>> allowing loading from contexts not possible prior to XMLC 2.3.2, su=
ch
>>>>> as the servlet context... or even a database.=A0=A0Loading from a c=
lass
>>>>> loader is merely one option, albeit a built-in default one as it ha=
s
>>>>> been available (along with loading from configured resource
>>>>> directories) since the original XMLC 2.2 release.=A0=A0The custom o=
ne I
>>>>> created for you is a minimal implementation that simply overrides t=
he
>>>>> way URLs are obtained from the class loader in the default resource
>>>>> loader implementation.
>>>>>
>>>>> In my view, this is clearly a class loader bug.=A0=A0If the class l=
oader
>>>>> can actually see the resource and provide a URL, then that URL ough=
t
>>>>> to be a valid one.=A0=A0That Tomcat's StandardClassLoader is return=
ing an
>>>>> invalid URL is absolutely a bug that should be reported to, and
>>>>> corrected by, the Tomcat team.=A0=A0Supplying the thread context cl=
ass
>>>>> loader to the XMLCDeferredParsingFactory constructor is the obvious
>>>>> workaround.=A0=A0But it is a workaround only made necessary by a cl=
ass
>>>>> loader bug.
>>>>>
>>>>> That said, I recommend using the thread context class loader
>>>>> regardless of this particular class loader bug, as it provides the
>>>>> added benefit of allowing XMLC libraries in the server lib to be ab=
le
>>>>> to see classes and resources in a child classloader (e.g, the
>>>>> WebappClassLoader).
>>>>>
>>>>>> Don't know if this can be somehow configured to specify the custom
>>>>>> one? options.xmlc?
>>>>>>
>>>>> I really view this as outside the scope of XMLC configuration.=A0=A0=
That
>>>>> configuration is focused on template configuration, not how they ar=
e
>>>>> loaded.=A0=A0Besides, the resource loader is used to load options.x=
mlc.
>>>>> It's a chicken/egg problem.=A0=A0Application code has complete cont=
rol
>>>>> over how the XMLCDeferredParsingFactory is instantiated, so it is
>>>>> application code where this should be addressed.
>>>>>
>>>>> XMLCContext, if you so choose to use it, provides for various servl=
et
>>>>> context parameters that you can configure in web.xml to specify
>>>>> various things, including document loaders.=A0=A0And it **ALWAYS**
>>>>> instantiates the XMLCDeferredParsingFactory using the thread contex=
t
>>>>> class loader.=A0=A0See....
>>>>>
>>>>> http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%2Ftrun=
k%2Fxmlc%2Fexamples%2Ftomcat%2Fres%2Fwebapps%2Fxmlc%2FWEB-INF%2Fweb.xml.i=
n
>>>>>
>>>>>
>>>>> http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%2Ftrun=
k%2Fxmlc%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
>>>>> context.getXMLCDeferredParsingFactory();
>>>>>
>>>>>
>>>>> If you use this, your applications will be more configurable and ne=
ver
>>>>> run into invalid URLs again.
>>>>>
>>>>>
>>>>>> 2) Maybe it makes sense to implement the following patch to XMLC's
>>>>>> ResourceLoaderImpl:
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0 protected URL getPathURLFromClasspath(final Stri=
ng candidatePath) {
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0URL url =3D
>>>>>> Thread.currentThread().getContextClassLoader().getResource(candida=
tePath);
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (url=3D=3Dnull) {
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 url =3D fFactory.getPathURLFro=
mClasspath(candidatePath);
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return url;
>>>>>>=A0=A0=A0=A0=A0=A0}
>>>>>>
>>>>> Actually, it would be the thread context classloader that might be
>>>>> null, in the case that the code is not running under a JEE server t=
hat
>>>>> sets it.=A0=A0That said, it's an option to consider, e.g.,....
>>>>>
>>>>>=A0=A0=A0=A0=A0=A0protected URL getPathURLFromClasspath(final String=
 candidatePath) {
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ClassLoader loader =3D
>>>>> Thread.currentThread().getContextClassLoader();
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0if (loader !=3D null) {
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return loader..getResource=
(candidatePath);
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0}
>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return fFactory.getPathURLFromClasspat=
h(candidatePath);
>>>>>=A0=A0=A0=A0=A0=A0}
>>>>>
>>>>> But while this might transparently resolve your issue, it takes awa=
y
>>>>> the ability of the user to determine the class loader to use, which
>>>>> they can currently specify by supplying their class loader of choic=
e
>>>>> to the XMLCDeferredParsingFactory constructor.=A0=A0For this reason=
, I
>>>>> hesitate to implement this option.
>>>>>
>>>>>
>>>>>> 3) I found the place where we can patch Enhydra's MultiClassLoader
>>>>>> (similar way as the patch provided for XMLCDeferredParsingFactory)=
,
>>>>>> so that it returns the "right" resource path in the case of JAR
>>>>>> files, so actually from our side, there is no need for the
>>>>>> modification mentioned above.
>>>>> I take it your class loader wraps Tomcat's StandardClassLoader (whe=
n
>>>>> running under Tomcat, that is)?=A0=A0Maybe you should have it wrap =
the
>>>>> thread context class loader instead?=A0=A0That way, you avoid the
>>>>> StandardClassLoader's buggyness.=A0=A0In any case, there's no good =
reason
>>>>> for any class loader to return invalid URLs.=A0=A0Again, I urge you=
 to
>>>>> report this issue to the Tomcat developers so this issue can be
>>>>> properly fixed for everyone using Tomcat's StandardClassLoader.
>>>>>
>>>>>> 4) When implementing either the modification on ResourceLoaderImpl=
 or
>>>>>> changing MultiClassLoader, calculator and discRack applications ar=
e
>>>>>> working normally. However, the projectManagement application is
>>>>>> working only "partially"...maybe it is a completely new problem
>>>>>> there, or this is the similar one but somehow hidden and not so
>>>>>> obvious to determine (just to mention that application works norma=
lly
>>>>>> under EXACTLY THE SAME conditions under XMLC2.3-1).
>>>>>> The start page of projectManagement applications is generated
>>>>>> smoothly, when you log in as admin/enhydra, the next page is also =
OK.
>>>>>> However, when you click on the link "Employee" or "Customer", the
>>>>>> following exception is thrown:
>>>>>>
>>>>> This is a completely distinct problem.=A0=A0This is either an issue=
 with
>>>>> the LazyDOM or, possibly with Xerces itself.=A0=A0Did you try downg=
rading
>>>>> to the version of xercesImpl and xml-apis that came with XMLC-2.3.1=
?
>>>>> Please try that first.=A0=A0If you still get an error, let me know.=
=A0=A0I
>>>>> think there was a change to the lazydom for XMLC 2.3.2 (some bug
>>>>> fix).=A0=A0I can't recall exactly what it was, though.=A0=A0It's po=
ssible I
>>>>> introduced a regression.=A0=A0Only more testing will tell.
>>>>>
>>>>> BTW, is the "projectManagement" application runnable under
>>>>> Tomcat-Standalone or does it require Enhydra server?
>>>>>
>>>>>> org.w3c.dom.DOMException: NOT_FOUND_ERR: An attempt is made to
>>>>>> reference a node in a context where it does not exist.
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.xerces.dom.ParentNode.internalRemoveChild(Unknown Sourc=
e)
>>>>>>=A0=A0=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=A0=A0 at
>>>>>> org.enhydra.xml.lazydom.LazyElementNoNS.removeChild(LazyElementNoN=
S.java:338)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> projectmanagement.presentation.employees.Administering.handleDefau=
lt(Administering.java:80)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> projectmanagement.presentation.BasePO.handleEvent(BasePO.java:282)
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at projectmanagement.presentation.Ba=
sePO.run(BasePO.java:156)
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> com.lutris.appserver.server.httpPresentation.HttpPresentationManag=
er.runPresentationObj(Unknown
>>>>>> Source)
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> com.lutris.appserver.server.httpPresentation.HttpPresentationManag=
er.Run(Unknown
>>>>>> Source)
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresentat=
ionServlet.serviceDirect(HttpPresentationServlet.java:697)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresentat=
ionServlet.service(HttpPresentationServlet.java:822)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at javax.servlet.http.HttpServlet.se=
rvice(HttpServlet.java:717)
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(A=
pplicationFilterChain.java:290)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicati=
onFilterChain.java:206)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp=
erValve.java:233)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.catalina.core.StandardContextValve.invoke(StandardConte=
xtValve.java:191)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValv=
e.java:127)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValv=
e.java:102)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngine=
Valve.java:109)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.=
java:298)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProce=
ssor.java:861)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler=
.process(Http11AprProtocol.java:579)
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at
>>>>>> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java=
:1584)
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 at java.lang.Thread.run(Thread.java:=
662)
>>>>>>
>>>>>>
>>>>>> (I just modified a little bit original sources to print the stack
>>>>>> trace of the exception).
>>>>>>
>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0 table.removeChild(page.getElementTemplateR=
ow());
>>>>>>
>>>>>> The strange is that such exception does not happen when accessing
>>>>>> Project/Pay Rate/Worksheet links, and the code for this pages is
>>>>>> similar...removal of table template row happens.
>>>>>>
>>>>>> Can you give me some leads here?
>>>>>>
>>>>> See above for answers.
>>>>>
>>>>>> Greetings,
>>>>>> Sasa.
>>>>>>
>>>>>
>>>>> Jake
>>>>>
>>>>>> On 28-Mar-11 07:11, Jacob Kjome wrote:
>>>>>>> I tried out your calculator.war example and was able to replicate
>>>>>>> the problem.
>>>>>>> I've also tracked down the cause.=A0=A0It turns out that while XM=
LC
>>>>>>> 2.3.1 and 2.3.2
>>>>>>> still do essentially the same thing, there's a nuance in how sour=
ce
>>>>>>> file URLs are
>>>>>>> created.=A0=A0In XMLC 2.3.1, the classloader used to obtain the U=
RL is
>>>>>>> the same one
>>>>>>> that loaded the XMLC class file.=A0=A0In XMLC 2.3.2, it's the one
>>>>>>> provided to the
>>>>>>> XMLCDeferredParsingFactory constructor.
>>>>>>>
>>>>>>> Now, in the Tomcat demo application, this turns out to be the sam=
e
>>>>>>> classloader, as
>>>>>>> XMLCContext provides
>>>>>>> "Thread.currentThread().getContextClassLoader()" to the
>>>>>>> XMLCDeferredParsingFactory constructor and, of course, this ends =
up
>>>>>>> being the
>>>>>>> WebappClassLoader as it's a thread from the current application t=
hat
>>>>>>> is loading
>>>>>>> all the classes and the server sets this as the thread context cl=
ass
>>>>>>> loader for us.
>>>>>>>
>>>>>>> As it turns out, when URLs are created from the WebappClassLoader=
,
>>>>>>> loader.toString(), or loader.toExternalForm(), produces a valid J=
AR
>>>>>>> URL, such as...
>>>>>>>
>>>>>>> jar:file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/=
WEB-INF/lib/calculator.jar!/calculator/presentation/Calculator.html
>>>>>>>
>>>>>>>
>>>>>>> However, in the calculator application, the classloader provided =
to the
>>>>>>> XMLCDeferredParsingFactory constructor is actually the parent
>>>>>>> classloder of the
>>>>>>> WebappClassLoader and, under Tomcat Standalone, an instance of
>>>>>>> "org.apache.catalina.loader.StandardClassLoader".
>>>>>>>
>>>>>>> As it turns out, when URLs are created from the StandardClassLoad=
er,
>>>>>>> loader.toString(), or loader.toExternalForm(), produces an invali=
d
>>>>>>> JAR URL, such as...
>>>>>>>
>>>>>>> file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/WEB-=
INF/lib/calculator.jarcalculator/presentation/Calculator.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This subtle change in behavior was unforeseen and you are the fir=
st
>>>>>>> to report it.
>>>>>>>=A0=A0=A0=A0 I never encountered it in my testing because, as ment=
ioned
>>>>>>> previously, I always
>>>>>>> use the thread context class loader.=A0=A0Personally, I think it'=
s a bug
>>>>>>> in Tomcat, as
>>>>>>> it shouldn't matter what kind of class loader it is.=A0=A0All cla=
ss
>>>>>>> loaders ought to
>>>>>>> be able to generate valid jar URLs.=A0=A0I encourage you to repor=
t this
>>>>>>> to the Tomcat
>>>>>>> development team!
>>>>>>>
>>>>>>> At this point, there's no going back to the way XMLC 2.3.1 loaded
>>>>>>> URLs because of
>>>>>>> significant design changes.=A0=A0The point at which URLs are now =
loaded
>>>>>>> provides no
>>>>>>> access to the XMLC class file and, therefore, no way to obtain th=
e
>>>>>>> classloader
>>>>>>> that loaded the XMLC class file... that is, unless XMLC always us=
es
>>>>>>> the thread
>>>>>>> context classloader to load resources (more on that below).=A0=A0=
Anyway,
>>>>>>> here are the
>>>>>>> obvious fixes in my order of preference...
>>>>>>>
>>>>>>> 1.=A0=A0Always pass "Thread.currentThread().getContextClassLoader=
()" to the
>>>>>>> XMLCDeferredParsingFactory constructor.=A0=A0This resolves all is=
sues,
>>>>>>> end of story.
>>>>>>>
>>>>>>> 2.=A0=A0If #1 is not possible/desirable, then you can implement y=
our own
>>>>>>> custom
>>>>>>> document/resource loader, similar to what I attached to my last
>>>>>>> email (see the new
>>>>>>> version attached to this email); the only difference being the
>>>>>>> method to override
>>>>>>> now looks like...
>>>>>>>
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0protected URL getPathURLFromClasspath(fina=
l String
>>>>>>> candidatePath) {
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0return
>>>>>>> Thread.currentThread().getContextClassLoader().getResource(candid=
atePath);
>>>>>>>
>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0}
>>>>>>>
>>>>>>> 3.=A0=A0Change XMLC's
>>>>>>> XMLCDeferredParsingFactory.getPathURLFromClasspath(String)
>>>>>>> method to use the thread context classloader.=A0=A0While this is =
an
>>>>>>> option, it's not a
>>>>>>> very good one because the thread context class loader may not alw=
ays
>>>>>>> be the right
>>>>>>> choice.=A0=A0While it generally is the right choice 99.99999% of =
the
>>>>>>> time in a JEE
>>>>>>> environment, XMLC is not always used in a server environment.=A0=A0=
And
>>>>>>> there's always
>>>>>>> going to be that edge case where, even in a server environment it=
's
>>>>>>> not desirable.
>>>>>>>=A0=A0=A0=A0 And, of course, that's where option #1 really shines.=
=A0=A0You get to
>>>>>>> choose 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 =
highly
>>>>>>> resistant to #3.
>>>>>>> I realize the change in behavior is inconvenient (and most likely=
 a
>>>>>>> Tomcat bug
>>>>>>> anyway), but it's a simple change on the user's part and can be d=
one
>>>>>>> as part of
>>>>>>> the upgrade from 2.3.1 to 2.3.2.=A0=A0Besides, the design changes=
 that
>>>>>>> introduced this
>>>>>>> [easily-worked-around] situation make XMLC far more flexible in
>>>>>>> regard to resource
>>>>>>> loading than it was before.=A0=A0I think the benefits outweigh th=
e costs.
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>> 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" applicat=
ion
>>>>>>>> from
>>>>>>>> Enhydra Demos package. This sample uses only XMLC and Enhydra
>>>>>>>> Framework
>>>>>>>> classes (no database where we use our product DODS, and then JOT=
M and
>>>>>>>> other JTA support libraries).
>>>>>>>>
>>>>>>>> I deployed "calculator" application under pure Tomcat 6.0-29, JD=
K
>>>>>>>> 1.6.0_23 x64, Win7 x64.
>>>>>>>> It works normally. Then I first replaced xercesImpl, xml-apis an=
d
>>>>>>>> nekohtml JAR files with the newer versions from XMLC 2.3-2. It s=
till
>>>>>>>> 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\calculato=
r.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=3D0B9ZAe6ftekYJMGVmYjdmZDMtMjY5Y=
S00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=3Dname&layout=3Dlist&pid=3D0B9ZAe6ft=
ekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=3D18
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> (If necessary, you can find the source code of Enhydra Demos (TD=
A),
>>>>>>>> Enhydra Framework (TAF), Enhydra DODS (TRO) at:
>>>>>>>> https://docs.google.com/leaf?id=3D0B9ZAe6ftekYJNTc0OWM2NzctNzM3M=
S00YmNjLTkyMTctZjg0ZWUxZWI2YWQw&;hl=3Den
>>>>>>>>
>>>>>>>>
>>>>>>>> but to reproduce the problem, downloading the 1st link is enough=
)
>>>>>>>>
>>>>>>>> There are many applications based on XMLC included in the ZIP fi=
le
>>>>>>>> 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...s=
o 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.=A0=A0That goes for both XMLC 2.=
3.1 and
>>>>>>>>> 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 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.=A0=A0There's no "file:/" and all t=
he
>>>>>>>>> slashes are
>>>>>>>>> backward.=A0=A0This looks to me like a custom classloader bug.=A0=
=A0Again,
>>>>>>>>> XMLC doesn't
>>>>>>>>> generate the URL, the classloader does.
>>>>>>>>>
>>>>>>>>> When you say that "it works under 2.3.1", are you sure you test=
ed
>>>>>>>>> 2.3.1 with the
>>>>>>>>> same version of the server you are using to test 2.3.2?=A0=A0Th=
at 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 wit=
h 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'l=
l test
>>>>>>>>> it myself
>>>>>>>>> and let you know the results.
>>>>>>>>>
>>>>>>>>> BTW, here's how XMLCContext loads up the deferred parsing facto=
ry...
>>>>>>>>>
>>>>>>>>> XMLCDeferredParsingFactory newFactory
>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=3D new XMLCDeferredParsingF=
actory(loader,
>>>>>>>>> Thread.currentThread().getContextClassLoader(), logger);
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> First, notice that the classloader is set up as the thread cont=
ext
>>>>>>>>> class loader of
>>>>>>>>> the application.=A0=A0This is the reason why the XMLC Tomcat de=
mo
>>>>>>>>> works no
>>>>>>>>> matter
>>>>>>>>> where the XMLC libraries are located in relation to the jar
>>>>>>>>> containing
>>>>>>>>> the
>>>>>>>>> templates.=A0=A0When templates are in the parent classloader, t=
he webapp
>>>>>>>>> (child)
>>>>>>>>> classloader can always see that, so they load just fine.=A0=A0A=
nd when
>>>>>>>>> the
>>>>>>>>> templates
>>>>>>>>> are in the webapp classloader while the XMLC libraries are in t=
he
>>>>>>>>> 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 y=
ou
>>>>>>>>> would not run
>>>>>>>>> into the issues you have of not finding the templates in certai=
n
>>>>>>>>> situations.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Second, you can customize the loading of resources by using a c=
ustom
>>>>>>>>> DocumentLoader/ResourceLoader combo.=A0=A0See the
>>>>>>>>> ValidatingDocumentLoader
>>>>>>>>> example in
>>>>>>>>> the Tomcat demo....
>>>>>>>>>
>>>>>>>>> http://websvn.ow2.org/filedetails.php?repname=3Dxmlc&path=3D%2F=
tags%2FXMLC_2_3_2%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FValida=
tingDocumentLoader.java
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This one extends ServletDocumentLoaderImpl, but if you don't ca=
re
>>>>>>>>> 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=A0=A0 new EnhydraXMLCLogger(logChannel));
>>>>>>>>>
>>>>>>>>> ...use...
>>>>>>>>>
>>>>>>>>> xmlcFactory =3D new XMLCDeferredParsingFactory(new
>>>>>>>>> CustomDocumentLoader(),
>>>>>>>>>
>>>>>>>>> (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 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
>>>>>>>>> CustomDocumentLoader(),
>>>>>>>>>
>>>>>>>>> Thread.currentThread().getContextClassLoader(),
>>>>>>>>>=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));
>>>>>>>>>
>>>>>>>>> With the custom document/resource loader, you can change the be=
havior
>>>>>>>>> of resource
>>>>>>>>> loading without modifying the internals of XMLC at all.=A0=A0Th=
is feature
>>>>>>>>> is new to
>>>>>>>>> XMLC-2.3.2.=A0=A0However, remember that besides the added pluga=
bility
>>>>>>>>> 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 EVER=
YTHING
>>>>>>>>>> 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 sce=
nario
>>>>>>>>>> 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 thin=
k
>>>>>>>>>> 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.=A0=A0But=
 this is
>>>>>>>>>>> really not XMLC's fault.=A0=A0The classloader's getResource()=
 method is
>>>>>>>>>>> returning an invalid path.=A0=A0Other than tweaking it with y=
our
>>>>>>>>>>> workaround, there's nothing XMLC can (nor should) do about th=
at
>>>>>>>>>>> (though there is a way you can work around this without messi=
ng
>>>>>>>>>>> with
>>>>>>>>>>> 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=A0=
The
>>>>>>>>>>> first is
>>>>>>>>>>> Win7 x64, where I've only tested on WinXP x32.=A0=A0You may a=
lso be
>>>>>>>>>>> using
>>>>>>>>>>> 64 bit Java, though you'd have to verify that.=A0=A0And you a=
re running
>>>>>>>>>>> under Enhydra, with some "MultiClassLoader" classloader
>>>>>>>>>>> implementation.=A0=A0Somewhere in these differences lies a bu=
g that
>>>>>>>>>>> is not
>>>>>>>>>>> the fault of XMLC.
>>>>>>>>>>>
>>>>>>>>>>> I would start first with the "MultiClasLoader" and see whethe=
r
>>>>>>>>>>> there
>>>>>>>>>>> is a bug in its getResource() method that returns URL's with
>>>>>>>>>>> invalid
>>>>>>>>>>> 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 vers=
ion
>>>>>>>>>>> has 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 woul=
d be
>>>>>>>>>>> responsible for working around that given the supposed "platf=
orm
>>>>>>>>>>> independence" and all.
>>>>>>>>>>>
>>>>>>>>>>> Expect another email describing a workaround you can use, wit=
hout
>>>>>>>>>>> messing with XMLC's core, a bit later when I have access to m=
y
>>>>>>>>>>> development machine.
>>>>>>>>>>>
>>>>>>>>>>> Jake
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, 24 Mar 2011 22:41:23 +0100
>>>>>>>>>>>=A0=A0=A0=A0=A0=A0Sasa Bojanic<[email protected]>=A0=A0=A0=A0w=
rote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> from what I can see in Enhydra code, XMLCDeferredParsingFact=
ory is
>>>>>>>>>>>> obtained by calling its constructor:
>>>>>>>>>>>>
>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0xmlcFactory =3D new
>>>>>>>>>>>> XMLCDeferredParsingFactory(StandardDocumentLoader.getInstanc=
e(),
>>>>>>>>>>>>
>>>>>>>>>>>> (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=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 docume=
nt...
>>>>>>>>>>>>
>>>>>>>>>>>> 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\*discRa=
ck.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 report=
ed.
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> 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 use=
d
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> xmlc tomcat
>>>>>>>>>>>>> demo), thus could only be loaded via the classloader.=A0=A0=
I
>>>>>>>>>>>>> placed the
>>>>>>>>>>>>> templates jar
>>>>>>>>>>>>> in WEB-INF/lib and ran tomcat.=A0=A0First I tried loading t=
he
>>>>>>>>>>>>> Welcome.html page
>>>>>>>>>>>>> (french locale, because that's what I had selected in the t=
omcat
>>>>>>>>>>>>> demo), 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.Welcom=
e.html
>>>>>>>>>>>>> from source URL
>>>>>>>>>>>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/exampl=
es/tomcat/build/webapps/xmlc/WEB-INF/lib/xmlc-templates.jar!/demo/Welcome=
_fr.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...so, clearly it is being loaded via the classloader... an=
d
>>>>>>>>>>>>> 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 jar=
s,
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> common
>>>>>>>>>>>>> loader.=A0=A0It looks like...
>>>>>>>>>>>>>
>>>>>>>>>>>>> common.loader=3D${catalina.base}/shared,${catalina.base}/sh=
ared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar,${catali=
na.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.=A0=A0Again I tried loading the Welcome.html pa=
ge and,
>>>>>>>>>>>>> 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 look=
ed like...
>>>>>>>>>>>>>
>>>>>>>>>>>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcom=
e.html
>>>>>>>>>>>>> from source URL
>>>>>>>>>>>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/exampl=
es/tomcat/build/shared/xmlc-templates.jar!/demo/Welcome_fr.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not sure what to tell you?=A0=A0It all works fine for m=
e.=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
>>>>>>>>>>>>> XMLCDeferredParsingFactory.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> At this point, I can only say that it works for me.=A0=A0Ma=
ybe the
>>>>>>>>>>>>> it's
>>>>>>>>>>>>> platform
>>>>>>>>>>>>> differences that are causing issues?=A0=A0What OS and versi=
on 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)?=A0=A0A=
nd
>>>>>>>>>>>>> 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 X=
MLC 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 lik=
e
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> Xerces
>>>>>>>>>>>>>>> does
>>>>>>>>>>>>>>> so.=A0=A0Plus it makes for easy testing because JDK1.3 do=
esn't add
>>>>>>>>>>>>>>> any of
>>>>>>>>>>>>>>> its own XML libraries.=A0=A0It's easy to dictate the vers=
ion
>>>>>>>>>>>>>>> without
>>>>>>>>>>>>>>> getting buggy JDK1.4 XML behavior.=A0=A0But I think most =
of the
>>>>>>>>>>>>>>> world has
>>>>>>>>>>>>>>> moved on to JDK1.5+, so maybe XMLC should too at some poi=
nt?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'll have to test #2.=A0=A0Not sure how quickly I'll be a=
ble 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=A0=A0=A0=A0=A0=A0Sasa Bojanic<[email protected]>=A0=
=A0=A0=A0 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 p=
laced
>>>>>>>>>>>>>>>> together with the application JAR files into application=
's
>>>>>>>>>>>>>>>> WEB-INF\lib folder (so application classloader is used t=
o load
>>>>>>>>>>>>>>>> them).
>>>>>>>>>>>>>>>> In this case, XMLC can't load resources (*.html and *.xm=
lc
>>>>>>>>>>>>>>>> files)
>>>>>>>>>>>>>>>> from JAR file. When resources are not in the JAR file bu=
t
>>>>>>>>>>>>>>>> unpacked
>>>>>>>>>>>>>>>> into WEB-INF\classes folder everything works.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> After "patching" the method getPathURLFromClasspath() fr=
om
>>>>>>>>>>>>>>>> XMLCDeferredParsingFactory to add:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>=A0=A0=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=A0=A0=
=A0try {
>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 String mdurl =3D srcURL.toString();
>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 srcURL =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=A0=A0+ mdurl.su=
bstring(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=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=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=A0=A0=A0=A0}
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> after the line:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0URL srcURL =3D
>>>>>>>>>>>>>>>> fDynamicClassLoader.getResource(path);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> it works fine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) when deploying under Enhydra application server or un=
der
>>>>>>>>>>>>>>>> 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 in=
to
>>>>>>>>>>>>>>>> Tomcat's
>>>>>>>>>>>>>>>> lib folder.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is it a bug in XMLC? Can somebody help?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Sasa.
>>>>>>>>>>>>>>>>
>=20


------------=_1301408849-30467-16158
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

------------=_1301408849-30467-16158--