[xmlc] Re: Re: Re: Re: Issues with XMLC 2.3.2
Sasa Bojanic <[email protected]> Tue, 29 Mar 2011 07:48:35 +0200
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format... ------------=_1301377729-30467-16096 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I will try it soon and let you know...thanks again! Sasa. On 29-Mar-11 08:51, Jacob Kjome wrote: > 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. >>>>>>>>>>>>>>> ------------=_1301377729-30467-16096 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 ------------=_1301377729-30467-16096--