[xmlc] Re: Re: Issues with XMLC 2.3.2
Jacob Kjome <[email protected]> Tue, 29 Mar 2011 00:06:23 -0600
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format... ------------=_1301374928-30467-16092 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've narrowed down the DOMException NOT_FOUND_ERR problem to nekohtml. When I use version 1.9.8, which is distributed with XMLC 2.3.1, everything works fine, even with XMLC 2.3.2. But when I use version 1.9.14, I get the error you reported, even with XMLC 2.3.1. I backtracked through the versions of nekohtml to find the latest version that would work. I discovered that version 1.9.12 works fine, but 1.9.13 fails. So, something introduced in 1.9.13 is causing the problem. I'll try to do some more digging this week to figure out what the root cause is. It would be great if you could do the same. When we can pinpoint the issue, we can report it as a 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 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. >>>>>>>>>>>>> >>> >> > ------------=_1301374928-30467-16092 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 ------------=_1301374928-30467-16092--