[xmlc] Re: Re: Re: Issues with XMLC 2.3.2
Jacob Kjome <[email protected]> Tue, 29 Mar 2011 00:51:41 -0600
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format... ------------=_1301377491-30467-16095 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I suspect nekohtml is manipulating the table in ways you didn't expect. 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 child of TABLE, but TBODY, which could very well explain the error you are seeing. It seems to me that safer code would be... page.getElementTemplateRow().getParentNode().removeChild(page.getElementTemplateRow()); Can you try that and let me know if the issue goes away with nekohtml 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. 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. >>>>>>>>>>>>>> >>>> >>> >> ------------=_1301377491-30467-16095 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 ------------=_1301377491-30467-16095--