[xmlc] Re: 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...

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

My mistake about the "general" problem...now I see that generated XMLC 
Java classes have non-default constructor taking DocumentLoader object 
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=0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=name&layout=list&pid=0B9ZAe6ftekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=18

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
>  Sasa Bojanic <[email protected]> wrote:
>> Jake, first of all, thanks a lot for your effort!
>>
>
> No problem.  I 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 use 
>> StandardDocumentLoader.
>
> I'm not sure I understand how this is a "general problem" with 
> document/resource loaders.  Keep in mind, they are resource location 
> generic, i.e., they are meant to make resource loading plugable, 
> allowing loading from contexts not possible prior to XMLC 2.3.2, such 
> as the servlet context... or even a database.  Loading from a class 
> loader is merely one option, albeit a built-in default one as it has 
> been available (along with loading from configured resource 
> directories) since the original XMLC 2.2 release.  The custom one I 
> created for you is a minimal implementation that simply overrides the 
> way URLs are obtained from the class loader in the default resource 
> loader implementation.
>
> In my view, this is clearly a class loader bug.  If the class loader 
> can actually see the resource and provide a URL, then that URL ought 
> to be a valid one.  That Tomcat's StandardClassLoader is returning an 
> invalid URL is absolutely a bug that should be reported to, and 
> corrected by, the Tomcat team.  Supplying the thread context class 
> loader to the XMLCDeferredParsingFactory constructor is the obvious 
> workaround.  But it is a workaround only made necessary by a class 
> 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 able 
> 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.  That 
> configuration is focused on template configuration, not how they are 
> loaded.  Besides, the resource loader is used to load options.xmlc.  
> It's a chicken/egg problem.  Application code has complete control 
> 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 servlet 
> context parameters that you can configure in web.xml to specify 
> various things, including document loaders.  And it **ALWAYS** 
> instantiates the XMLCDeferredParsingFactory using the thread context 
> class loader.  See....
>
> http://websvn.ow2.org/filedetails.php?repname=xmlc&path=%2Ftrunk%2Fxmlc%2Fexamples%2Ftomcat%2Fres%2Fwebapps%2Fxmlc%2FWEB-INF%2Fweb.xml.in 
>
>
> http://websvn.ow2.org/filedetails.php?repname=xmlc&path=%2Ftrunk%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FPreview.java 
>
>
>
> All you need to do to access it is...
>
> XMLCContext context = XMLCContext.getContext(servletObj);
> ...or...
> XMLCContext context = XMLCContext.getContext(servletContextObj);
>
> ...and then...
> XMLCDeferredParsingFactory dpFactory = 
> context.getXMLCDeferredParsingFactory();
>
>
> If you use this, your applications will be more configurable and never 
> run into invalid URLs again.
>
>
>> 2) Maybe it makes sense to implement the following patch to XMLC's 
>> ResourceLoaderImpl:
>>
>>      protected URL getPathURLFromClasspath(final String candidatePath) {
>>         URL url = 
>> Thread.currentThread().getContextClassLoader().getResource(candidatePath);
>>         if (url==null) {
>>            url = fFactory.getPathURLFromClasspath(candidatePath);
>>         }
>>         return url;
>>     }
>>
>
> 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 that 
> sets it.  That said, it's an option to consider, e.g.,....
>
>     protected URL getPathURLFromClasspath(final String candidatePath) {
>         ClassLoader loader = 
> Thread.currentThread().getContextClassLoader();
>         if (loader != null) {
>             return loader..getResource(candidatePath);
>         }
>         return fFactory.getPathURLFromClasspath(candidatePath);
>     }
>
> But while this might transparently resolve your issue, it takes away 
> the ability of the user to determine the class loader to use, which 
> they can currently specify by supplying their class loader of choice 
> to the XMLCDeferredParsingFactory constructor.  For 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 (when 
> running under Tomcat, that is)?  Maybe you should have it wrap the 
> thread context class loader instead?  That way, you avoid the 
> StandardClassLoader's buggyness.  In any case, there's no good reason 
> for any class loader to return invalid URLs.  Again, 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 are 
>> 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 normally 
>> 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.  This is either an issue with 
> the LazyDOM or, possibly with Xerces itself.  Did you try downgrading 
> to the version of xercesImpl and xml-apis that came with XMLC-2.3.1?  
> Please try that first.  If you still get an error, let me know.  I 
> think there was a change to the lazydom for XMLC 2.3.2 (some bug 
> fix).  I can't recall exactly what it was, though.  It's possible I 
> introduced a regression.  Only 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.
>>          at 
>> org.apache.xerces.dom.ParentNode.internalRemoveChild(Unknown Source)
>>          at org.apache.xerces.dom.ParentNode.removeChild(Unknown Source)
>>          at 
>> org.enhydra.xml.lazydom.LazyElementNoNS.removeChild(LazyElementNoNS.java:338)
>>          at 
>> projectmanagement.presentation.employees.Administering.handleDefault(Administering.java:80)
>>          at 
>> projectmanagement.presentation.BasePO.handleEvent(BasePO.java:282)
>>          at projectmanagement.presentation.BasePO.run(BasePO.java:156)
>>          at 
>> com.lutris.appserver.server.httpPresentation.HttpPresentationManager.runPresentationObj(Unknown 
>> Source)
>>          at 
>> com.lutris.appserver.server.httpPresentation.HttpPresentationManager.Run(Unknown 
>> Source)
>>          at 
>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.serviceDirect(HttpPresentationServlet.java:697)
>>          at 
>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.service(HttpPresentationServlet.java:822)
>>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>>          at 
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>>          at 
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>>          at 
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>>          at 
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>>          at 
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>>          at 
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>>          at 
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>>          at 
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
>>          at 
>> org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861)
>>          at 
>> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
>>          at 
>> org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)
>>          at java.lang.Thread.run(Thread.java:662)
>>
>>
>> (I just modified a little bit original sources to print the stack 
>> trace of the exception).
>>
>>        table.removeChild(page.getElementTemplateRow());
>>
>> 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.  It turns out that while XMLC 
>>> 2.3.1 and 2.3.2
>>> still do essentially the same thing, there's a nuance in how source 
>>> file URLs are
>>> created.  In XMLC 2.3.1, the classloader used to obtain the URL is 
>>> the same one
>>> that loaded the XMLC class file.  In 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 same 
>>> 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 that 
>>> is loading
>>> all the classes and the server sets this as the thread context class 
>>> loader for us.
>>>
>>> As it turns out, when URLs are created from the WebappClassLoader,
>>> loader.toString(), or loader.toExternalForm(), produces a valid JAR 
>>> 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 StandardClassLoader,
>>> loader.toString(), or loader.toExternalForm(), produces an invalid 
>>> 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 first 
>>> to report it.
>>>    I never encountered it in my testing because, as mentioned 
>>> previously, I always
>>> use the thread context class loader.  Personally, I think it's a bug 
>>> in Tomcat, as
>>> it shouldn't matter what kind of class loader it is.  All class 
>>> loaders ought to
>>> be able to generate valid jar URLs.  I encourage you to report 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.  The point at which URLs are now loaded 
>>> provides no
>>> access to the XMLC class file and, therefore, no way to obtain the 
>>> classloader
>>> that loaded the XMLC class file... that is, unless XMLC always uses 
>>> the thread
>>> context classloader to load resources (more on that below).  Anyway, 
>>> here are the
>>> obvious fixes in my order of preference...
>>>
>>> 1.  Always pass "Thread.currentThread().getContextClassLoader()" to the
>>> XMLCDeferredParsingFactory constructor.  This resolves all issues, 
>>> end of story.
>>>
>>> 2.  If #1 is not possible/desirable, then you can implement your 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...
>>>
>>>       protected URL getPathURLFromClasspath(final String 
>>> candidatePath) {
>>>           return
>>> Thread.currentThread().getContextClassLoader().getResource(candidatePath); 
>>>
>>>       }
>>>
>>> 3.  Change XMLC's 
>>> XMLCDeferredParsingFactory.getPathURLFromClasspath(String)
>>> method to use the thread context classloader.  While this is an 
>>> option, it's not a
>>> very good one because the thread context class loader may not always 
>>> be the right
>>> choice.  While it generally is the right choice 99.99999% of the 
>>> time in a JEE
>>> environment, XMLC is not always used in a server environment.  And 
>>> there's always
>>> going to be that edge case where, even in a server environment it's 
>>> not desirable.
>>>    And, of course, that's where option #1 really shines.  You get to 
>>> choose which
>>> classloader to use so XMLC doesn't have to guess.
>>>
>>> 4.  If you can think of a better idea, let me know.  I'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 done 
>>> as part of
>>> the upgrade from 2.3.1 to 2.3.2.  Besides, the design changes that 
>>> introduced this
>>> [easily-worked-around] situation make XMLC far more flexible in 
>>> regard to resource
>>> loading than it was before.  I think the benefits outweigh the 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" application 
>>>> from
>>>> Enhydra Demos package. This sample uses only XMLC and Enhydra 
>>>> Framework
>>>> classes (no database where we use our product DODS, and then JOTM and
>>>> other JTA support libraries).
>>>>
>>>> I deployed "calculator" application under pure Tomcat 6.0-29, JDK
>>>> 1.6.0_23 x64, Win7 x64.
>>>> It works normally. Then I first replaced xercesImpl, xml-apis and
>>>> nekohtml JAR files with the newer versions from XMLC 2.3-2. It still
>>>> worked normally.
>>>> After I finally replaced xmlc.jar (2.3-1) with xmlc-all-runtime.jar,
>>>> removed gnu-regexp.jar and introduced jregex.jar, I get the 1st
>>>> described problem with not being able to find the resource from the 
>>>> JAR
>>>> file:
>>>>
>>>> java.io.FileNotFoundException:
>>>> d:\apache-tomcat-6.0.29\webapps\calculator\WEB-INF\lib\calculator.jarcalculator\presentation\CalculatorHTML.xmlc 
>>>>
>>>> (The system cannot find the path specified)
>>>>
>>>> You can download a set of Enhydra Demo applications (version 8.4-1) 
>>>> for
>>>> pure Tomcat from:
>>>>
>>>> https://docs.google.com/leaf?id=0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=name&layout=list&pid=0B9ZAe6ftekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=18 
>>>>
>>>>
>>>>
>>>> (If necessary, you can find the source code of Enhydra Demos (TDA),
>>>> Enhydra Framework (TAF), Enhydra DODS (TRO) at:
>>>> https://docs.google.com/leaf?id=0B9ZAe6ftekYJNTc0OWM2NzctNzM3MS00YmNjLTkyMTctZjg0ZWUxZWI2YWQw&;hl=en 
>>>>
>>>>
>>>> but to reproduce the problem, downloading the 1st link is enough)
>>>>
>>>> There are many applications based on XMLC included in the ZIP file 
>>>> from
>>>> the 1st link above, ready to be deployed on pure Tomcat.
>>>> As the simplest one for testing you can take "calculator.war" I used
>>>> this time.
>>>>
>>>> After I provide a "patch/workaround" for this problem of finding
>>>> resource in the JAR file, the problem disappears.
>>>>
>>>> When I moved all the JAR files except the application JAR file
>>>> (calculator.jar) to the common/shared class-loader (Tomcat's lib
>>>> folder), this time I do NOT have the 2nd problem I described...so that
>>>> might be my mistake during previous tests. The 2nd problem also 
>>>> does NOT
>>>> appear with "discRack" application either. So I assume the
>>>> "patch/workaround" somehow solves all the problems.
>>>>
>>>> Since the ONLY difference with the deployment of this sample
>>>> XMLC/Enhydra Framework/DODS applications is the version of XMLC, 
>>>> can you
>>>> please look at that samples yourself, and confirm the issue.
>>>>
>>>> Greetings,
>>>> Sasa.
>>>>
>>>>
>>>> On 26-Mar-11 20:14, Jacob Kjome wrote:
>>>>> The thing is, XMLC doesn't create the URL object that provides the
>>>>> path to the
>>>>> resource; the classloader does.  That goes for both XMLC 2.3.1 and
>>>>> 2.3.2.  I can't
>>>>> explain why behavior would be different for you between the two
>>>>> versions?  Of
>>>>> course, I can't replicate your findings in the first place, so I'm at
>>>>> a loss.
>>>>>
>>>>> One thing that is a red flag for me is the path you provided...
>>>>>
>>>>> "d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRack.jardiscRack*\presentation\ErrorHTML.xmlc" 
>>>>>
>>>>>
>>>>>
>>>>> That isn't even a valid URL.  There's no "file:/" and all the 
>>>>> slashes are
>>>>> backward.  This looks to me like a custom classloader bug.  Again,
>>>>> XMLC doesn't
>>>>> generate the URL, the classloader does.
>>>>>
>>>>> When you say that "it works under 2.3.1", are you sure you tested
>>>>> 2.3.1 with the
>>>>> same version of the server you are using to test 2.3.2?  That is, 
>>>>> when
>>>>> you tested
>>>>> 2.3.1, was the server an older version than what you are using with
>>>>> 2.3.2?  If so,
>>>>> please reduce the number of extraneous variables by testing with the
>>>>> older server
>>>>> version (the one known to work) and just switching out the 2.3.1
>>>>> libraries with
>>>>> the 2.3.2 libraries.  Do you get better results?
>>>>>
>>>>> If you can send me a minimal webapp (able to run under Tomcat
>>>>> standalone) with
>>>>> explicit instructions on how to replicate the problem, then I'll test
>>>>> it myself
>>>>> and let you know the results.
>>>>>
>>>>> BTW, here's how XMLCContext loads up the deferred parsing factory...
>>>>>
>>>>> XMLCDeferredParsingFactory newFactory
>>>>>           = new XMLCDeferredParsingFactory(loader,
>>>>> Thread.currentThread().getContextClassLoader(), logger);
>>>>>
>>>>>
>>>>> First, notice that the classloader is set up as the thread context
>>>>> class loader of
>>>>> the application.  This is the reason why the XMLC Tomcat demo 
>>>>> works no
>>>>> matter
>>>>> where the XMLC libraries are located in relation to the jar 
>>>>> containing
>>>>> the
>>>>> templates.  When templates are in the parent classloader, the webapp
>>>>> (child)
>>>>> classloader can always see that, so they load just fine.  And when 
>>>>> the
>>>>> templates
>>>>> are in the webapp classloader while the XMLC libraries are in the
>>>>> parent, XMLC can
>>>>> see down to the child classloader because it has a reference to 
>>>>> the child
>>>>> classloader via the thread context classloader.
>>>>>
>>>>> Clearly the "(MultiClassLoader)
>>>>> presentationManager.getAppClassLoader()" doesn't
>>>>> have a reference to the thread context classloader, otherwise you
>>>>> would not run
>>>>> into the issues you have of not finding the templates in certain
>>>>> situations.
>>>>>
>>>>>
>>>>> Second, you can customize the loading of resources by using a custom
>>>>> DocumentLoader/ResourceLoader combo.  See the 
>>>>> ValidatingDocumentLoader
>>>>> example in
>>>>> the Tomcat demo....
>>>>>
>>>>> http://websvn.ow2.org/filedetails.php?repname=xmlc&path=%2Ftags%2FXMLC_2_3_2%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FValidatingDocumentLoader.java 
>>>>>
>>>>>
>>>>>
>>>>> This one extends ServletDocumentLoaderImpl, but if you don't care
>>>>> about loading
>>>>> resources from the servlet context, then you can just extend
>>>>> DocumentLoaderImpl.
>>>>> Attached is a sample you can use.  Instead of using
>>>>> StandardDocumentLoader.getInstance() in the following...
>>>>>
>>>>> xmlcFactory = new
>>>>> XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
>>>>>
>>>>> (MultiClassLoader)presentationManager.getAppClassLoader(),
>>>>>                                new EnhydraXMLCLogger(logChannel));
>>>>>
>>>>> ...use...
>>>>>
>>>>> xmlcFactory = new XMLCDeferredParsingFactory(new 
>>>>> CustomDocumentLoader(),
>>>>>
>>>>> (MultiClassLoader)presentationManager.getAppClassLoader(),
>>>>>                                new EnhydraXMLCLogger(logChannel));
>>>>>
>>>>> ...and if you want to be able to load resources no matter where they
>>>>> exist in the
>>>>> classloader hierarchy relative to where XMLC libraries exist in the
>>>>> hierarchy use...
>>>>>
>>>>> xmlcFactory = new XMLCDeferredParsingFactory(new 
>>>>> CustomDocumentLoader(),
>>>>>
>>>>> Thread.currentThread().getContextClassLoader(),
>>>>>                     new EnhydraXMLCLogger(logChannel));
>>>>>
>>>>> With the custom document/resource loader, you can change the behavior
>>>>> of resource
>>>>> loading without modifying the internals of XMLC at all.  This feature
>>>>> is new to
>>>>> XMLC-2.3.2.  However, remember that besides the added plugability
>>>>> provided by
>>>>> XMLC-2.3.2, ultimately, XMLC 2.3.1 and 2.3.2 don't do anything
>>>>> different to load
>>>>> resources from the classloader.  They both use
>>>>> classLoader.getResource("some/path/to/resoruce.html").  If that
>>>>> provides a URL
>>>>> producing an invalid path, that's a bug in the classloader, not XMLC.
>>>>>
>>>>>
>>>>> Jake
>>>>>
>>>>> On 3/25/2011 9:14 AM, Sasa Bojanic wrote:
>>>>>> Hi,
>>>>>>
>>>>>> yes, I'm of course also using 64-bit Java.
>>>>>>
>>>>>> I will check about our MultiClassLoader, but the point is EVERYTHING
>>>>>> WORKS PERFECTLY with XMLC 2.3-1. We don't have a problem with 
>>>>>> resource
>>>>>> lookup within the JAR file, and do not have a problem with scenario
>>>>>> where XMLC is not in the application's classloader.
>>>>>>
>>>>>> We are trying to find the reason why we can't switch to XMLC 2.3-2
>>>>>> seamlessly...and since everything works with XMLC2.3-1 we think 
>>>>>> it is a
>>>>>> XMLC issue?
>>>>>>
>>>>>> Regards,
>>>>>> Sasa.
>>>>>>
>>>>>> On 25-Mar-11 16:03, Jacob Kjome wrote:
>>>>>>> In this particular case, XMLC can certainly find the file (as 
>>>>>>> opposed
>>>>>>> to the other case where it can't when XMLC libs are in the 
>>>>>>> server lib,
>>>>>>> at least on your system), but the path is messed up.  But this is
>>>>>>> really not XMLC's fault.  The classloader's getResource() method is
>>>>>>> returning an invalid path.  Other than tweaking it with your
>>>>>>> workaround, there's nothing XMLC can (nor should) do about that
>>>>>>> (though there is a way you can work around this without messing 
>>>>>>> with
>>>>>>> XMLC's core, which I will send in a separate email later 
>>>>>>> today).  As I
>>>>>>> mentioned, it works perfectly well on my system.
>>>>>>>
>>>>>>> You have, potentially, at least 3 platform differences.  The 
>>>>>>> first is
>>>>>>> Win7 x64, where I've only tested on WinXP x32.  You may also be 
>>>>>>> using
>>>>>>> 64 bit Java, though you'd have to verify that.  And you are running
>>>>>>> under Enhydra, with some "MultiClassLoader" classloader
>>>>>>> implementation.  Somewhere in these differences lies a bug that 
>>>>>>> is not
>>>>>>> the fault of XMLC.
>>>>>>>
>>>>>>> I would start first with the "MultiClasLoader" and see whether 
>>>>>>> there
>>>>>>> is a bug in its getResource() method that returns URL's with 
>>>>>>> invalid
>>>>>>> paths when resources are looked up in jar files.  Second, I'd 
>>>>>>> check if
>>>>>>> there's a bug in the JDK you are using (maybe the 64 bit version 
>>>>>>> has a
>>>>>>> bug where the 32 bit version I use does not?).  Third, I guess 
>>>>>>> could
>>>>>>> be a bug in Win7, though I would think the Java platform would be
>>>>>>> responsible for working around that given the supposed "platform
>>>>>>> independence" and all.
>>>>>>>
>>>>>>> Expect another email describing a workaround you can use, without
>>>>>>> messing with XMLC's core, a bit later when I have access to my
>>>>>>> development machine.
>>>>>>>
>>>>>>> Jake
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 24 Mar 2011 22:41:23 +0100
>>>>>>>     Sasa Bojanic<[email protected]>   wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> from what I can see in Enhydra code, XMLCDeferredParsingFactory is
>>>>>>>> obtained by calling its constructor:
>>>>>>>>
>>>>>>>>           xmlcFactory = new
>>>>>>>> XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
>>>>>>>>
>>>>>>>> (MultiClassLoader) presentationManager.getAppClassLoader(),
>>>>>>>>                                                        new
>>>>>>>> EnhydraXMLCLogger(logChannel));
>>>>>>>>
>>>>>>>> First of all let me show you an error that occurs when XMLC is 
>>>>>>>> in the
>>>>>>>> application classloader. The error is in the attached document...
>>>>>>>>
>>>>>>>> I use Tomcat 6.0.29, Java 1.6_23, Win7 x64, and all the JARs 
>>>>>>>> you've
>>>>>>>> mentioned are in this case in the application's WEB-INF\lib 
>>>>>>>> folder.
>>>>>>>>
>>>>>>>> If you notice, the XMLC is reporting to search for:
>>>>>>>>
>>>>>>>> d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRack.jardiscRack*\presentation\ErrorHTML.xmlc 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> When I "patch" XMLC as described before, this scenario works well.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Sasa.
>>>>>>>>
>>>>>>>> On 21-Mar-11 00:34, Jacob Kjome wrote:
>>>>>>>>> Hi Sasa,
>>>>>>>>>
>>>>>>>>> I finally made some time to look into the issues you reported.
>>>>>>>>> Interestingly, I'm
>>>>>>>>> not able to reproduce either issue.  I used Tomcat-6.0.29
>>>>>>>>> standalone, as that's
>>>>>>>>> the version you used (note that I did not try Enhydra).
>>>>>>>>>
>>>>>>>>> To test issue #1, I jar'ed up the classes and markup files and 
>>>>>>>>> made
>>>>>>>>> sure to rename
>>>>>>>>> the resource dirs so files located there could not be 
>>>>>>>>> found.  I also
>>>>>>>>> renamed the
>>>>>>>>> WEB-INF/xmlc directory in the demo app to ensure templates 
>>>>>>>>> could not
>>>>>>>>> be loaded via
>>>>>>>>> the servlet context (allowed for by the custom
>>>>>>>>> ValidatingDocumentLoader.ValidatingResourceLoader class used 
>>>>>>>>> in the
>>>>>>>>> xmlc tomcat
>>>>>>>>> demo), thus could only be loaded via the classloader.  I 
>>>>>>>>> placed the
>>>>>>>>> templates jar
>>>>>>>>> in WEB-INF/lib and ran tomcat.  First I tried loading the
>>>>>>>>> Welcome.html page
>>>>>>>>> (french locale, because that's what I had selected in the tomcat
>>>>>>>>> demo), which came
>>>>>>>>> up fine.  I took a look at the log to see how the file was 
>>>>>>>>> loaded...
>>>>>>>>>
>>>>>>>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcome.html
>>>>>>>>> from source URL
>>>>>>>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/tomcat/build/webapps/xmlc/WEB-INF/lib/xmlc-templates.jar!/demo/Welcome_fr.html 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ...so, clearly it is being loaded via the classloader... and 
>>>>>>>>> working
>>>>>>>>> fine for me.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To test issue #2, I copied the following jars into
>>>>>>>>> ${catalina.base}/shared...
>>>>>>>>>
>>>>>>>>> jregex.jar
>>>>>>>>> nekohtml.jar
>>>>>>>>> resolver.jar
>>>>>>>>> xercesImpl.jar
>>>>>>>>> xml-apis.jar
>>>>>>>>> xmlc-all-runtime.jar
>>>>>>>>>
>>>>>>>>> Note that the Tomcat demo has a modified
>>>>>>>>> ${catalina.base}/conf/catalina.properties, which places the
>>>>>>>>> ${catalina.base}/shared directory, as well as contained jars, 
>>>>>>>>> in the
>>>>>>>>> common
>>>>>>>>> loader.  It looks like...
>>>>>>>>>
>>>>>>>>> common.loader=${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This would be no different than putting the jars in
>>>>>>>>> ${catalina.home}/lib, but
>>>>>>>>> avoids having to muck with the contents of the stock Tomcat
>>>>>>>>> installation.
>>>>>>>>>
>>>>>>>>> Anyway, I left my jar file containing the XMLC classes and
>>>>>>>>> templates in
>>>>>>>>> WEB-INF/lib.  Again I tried loading the Welcome.html page and,
>>>>>>>>> again, it came up
>>>>>>>>> fine.  I looked at the log and the INFO message was the same as
>>>>>>>>> above.  I then
>>>>>>>>> moved the templates jar file to the ${catalina.base}/shared
>>>>>>>>> directory and tried it
>>>>>>>>> again.  The page came up fine and the INFO message looked like...
>>>>>>>>>
>>>>>>>>> INFO:>>>Parsing DOM for $$XMLC_GENERATED$$.xmlc.demo.Welcome.html
>>>>>>>>> from source URL
>>>>>>>>> jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/tomcat/build/shared/xmlc-templates.jar!/demo/Welcome_fr.html 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure what to tell you?  It all works fine for me.  Note
>>>>>>>>> that my
>>>>>>>>> environment consists of...
>>>>>>>>>
>>>>>>>>> Windows XP sp3
>>>>>>>>> Java 1.6.0_24
>>>>>>>>> Tomcat-6.0.29 (standalone run from the command line)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Note that I use XMLCContext to obtain the 
>>>>>>>>> XMLCDeferredParsingFactory.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> At this point, I can only say that it works for me.  Maybe the 
>>>>>>>>> it's
>>>>>>>>> platform
>>>>>>>>> differences that are causing issues?  What OS and version of 
>>>>>>>>> Java do
>>>>>>>>> you use?
>>>>>>>>> What does the original "jar:" URL look like when you run it 
>>>>>>>>> (prior
>>>>>>>>> to having to
>>>>>>>>> muck with it to get it to work in your environment)?  And 
>>>>>>>>> please let
>>>>>>>>> me know how
>>>>>>>>> you obtain the XMLCDeferredParsingFactory.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jake
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/7/2011 1:46 PM, Sasa Bojanic wrote:
>>>>>>>>>> Well, it is not really a patch, but something that made my 
>>>>>>>>>> use case
>>>>>>>>>> one
>>>>>>>>>> working...I agree nowdays it would be reasonable to move XMLC to
>>>>>>>>>> JDK1.5
>>>>>>>>>> or even 1.6...
>>>>>>>>>>
>>>>>>>>>> Thanks a lot for the quick response!
>>>>>>>>>>
>>>>>>>>>> Sasa.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 07-Mar-11 17:13, Jacob Kjome wrote:
>>>>>>>>>>> I can look into using your patch for #1 (or something like 
>>>>>>>>>>> it) for
>>>>>>>>>>> the
>>>>>>>>>>> next XML release.  I think the primary issue here is that we've
>>>>>>>>>>> maintained a dependency on JDK1.3, which does not have
>>>>>>>>>>> java.net.URI.
>>>>>>>>>>> I've tried to maintain this minimum dependency as long as 
>>>>>>>>>>> Xerces
>>>>>>>>>>> does
>>>>>>>>>>> so.  Plus it makes for easy testing because JDK1.3 doesn't add
>>>>>>>>>>> any of
>>>>>>>>>>> its own XML libraries.  It's easy to dictate the version 
>>>>>>>>>>> without
>>>>>>>>>>> getting buggy JDK1.4 XML behavior.  But I think most of the
>>>>>>>>>>> world has
>>>>>>>>>>> moved on to JDK1.5+, so maybe XMLC should too at some point?
>>>>>>>>>>>
>>>>>>>>>>> I'll have to test #2.  Not sure how quickly I'll be able to 
>>>>>>>>>>> get to
>>>>>>>>>>> this, though.  But I'll try and spend some time this week on 
>>>>>>>>>>> it.
>>>>>>>>>>>
>>>>>>>>>>> Jake
>>>>>>>>>>>
>>>>>>>>>>> On Mon, 07 Mar 2011 13:56:15 +0100
>>>>>>>>>>>       Sasa Bojanic<[email protected]>    wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm trying to upgrade our applications that use XMLC 2.3.1 
>>>>>>>>>>>> to the
>>>>>>>>>>>> newest XMLC version.
>>>>>>>>>>>> Our applications are deployed both under the Tomcat 6.0.29
>>>>>>>>>>>> application server and Enhydra application server (based on 
>>>>>>>>>>>> Tomcat
>>>>>>>>>>>> 6.0.29).
>>>>>>>>>>>>
>>>>>>>>>>>> There are two issues I faced:
>>>>>>>>>>>>
>>>>>>>>>>>> 1) when deploying under the Tomcat, XMLC JAR files are placed
>>>>>>>>>>>> together with the application JAR files into application's
>>>>>>>>>>>> WEB-INF\lib folder (so application classloader is used to load
>>>>>>>>>>>> them).
>>>>>>>>>>>> In this case, XMLC can't load resources (*.html and *.xmlc 
>>>>>>>>>>>> files)
>>>>>>>>>>>> from JAR file. When resources are not in the JAR file but 
>>>>>>>>>>>> unpacked
>>>>>>>>>>>> into WEB-INF\classes folder everything works.
>>>>>>>>>>>>
>>>>>>>>>>>> After "patching" the method getPathURLFromClasspath() from
>>>>>>>>>>>> XMLCDeferredParsingFactory to add:
>>>>>>>>>>>>
>>>>>>>>>>>>             if (srcURL != null&&
>>>>>>>>>>>> srcURL.toString().indexOf(".jar")>= 0) {
>>>>>>>>>>>>                   try {
>>>>>>>>>>>>                      String mdurl = srcURL.toString();
>>>>>>>>>>>>                      srcURL = new URL("jar:"
>>>>>>>>>>>>                                       + mdurl.substring(0,
>>>>>>>>>>>> mdurl.indexOf(".jar")) + ".jar!/"
>>>>>>>>>>>>                                       +
>>>>>>>>>>>> mdurl.substring(mdurl.indexOf(".jar") + 4));
>>>>>>>>>>>>                   } catch (Exception ex) {
>>>>>>>>>>>>                }
>>>>>>>>>>>>             }
>>>>>>>>>>>>
>>>>>>>>>>>> after the line:
>>>>>>>>>>>>
>>>>>>>>>>>>             URL srcURL = 
>>>>>>>>>>>> fDynamicClassLoader.getResource(path);
>>>>>>>>>>>>
>>>>>>>>>>>> it works fine.
>>>>>>>>>>>>
>>>>>>>>>>>> 2) when deploying under Enhydra application server or under
>>>>>>>>>>>> Tomcat,
>>>>>>>>>>>> but instead of putting XMLC JAR files into application's
>>>>>>>>>>>> WEB-INF\lib,
>>>>>>>>>>>> we put it into Tomcat's lib folder, XMLC can't find 
>>>>>>>>>>>> resources no
>>>>>>>>>>>> matter if resources are inside JAR file or unpacked, and it 
>>>>>>>>>>>> can't
>>>>>>>>>>>> find it even in the case I put application's JAR file into
>>>>>>>>>>>> Tomcat's
>>>>>>>>>>>> lib folder.
>>>>>>>>>>>>
>>>>>>>>>>>> Is it a bug in XMLC? Can somebody help?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Sasa.
>>>>>>>>>>>>
>>
>


------------=_1301344147-30467-16073
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

------------=_1301344147-30467-16073--