[xmlc] Re: Re: Re: Re: Re: Issues with XMLC 2.3.2
Sasa Bojanic <[email protected]> Tue, 29 Mar 2011 22:11:38 +0200
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format... ------------=_1301429511-30467-16177 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Arghhhh....what an obvious solution....I overlooked that StandardDocumentLoader is not a REAL singleton class! This solution solves all the problems. Thanks a lot for all your help! Greetings, Sasa. On 29-Mar-11 16:25, Jacob Kjome wrote: > Good research. But my conclusion would be to not explicitly provide a > singleton instance of the document loader to the > XMLCDeferredParsingFactory constructor. Either pass in null (in which > case, a non-singleton StandardDocumentLoader is used by default) or a > non-singleton instance of your preferred document loader. > > Wouldn't that solve your issue? > > Jake > > On Tue, 29 Mar 2011 13:41:51 +0200 > Sasa Bojanic <[email protected]> wrote: >> And again :-) >> >> The change with new XMLC is that when searching for source URLs - >> findSourceURL method of DocumentLoaderImpl, now the Classloader >> provided to the last created XMLCDeferredParsingFactory is used, >> while XMLC2.3-1 used the Classloader which was used to load the Class >> provided as an argument to findSourceURL method (which was in most of >> the cases the same one that is also loading other resources). >> >> That's why I would suggest (to make XMLC being able to "sit" in the >> shared classloader) the change in XMLCDeferredParsingFactory similar >> to the one I posted the last time: >> >> public final URL getPathURLFromClasspath(String path) { >> URL srcURL = fDynamicClassLoader.getResource(path); >> if (srcURL==null) { >> ClassLoader loader = >> Thread.currentThread().getContextClassLoader(); >> if (loader!=null) { >> srcURL = loader.getResource(path); >> } >> } >> if ((srcURL != null) && getLogger().debugEnabled()) { >> getLogger().logDebug(">>>Get document '" >> + srcURL >> + "' from classpath"); >> } >> return srcURL; >> } >> >> This way, we always try to use the class loader "registered" with >> XMLCDeferredParsingFactory, and if resource is not found, we use >> current thread's class loader. >> That would solve the issues with XMLC "sitting" in the shared LIB, >> and in other scenarios it would behave like it is today. >> >> Of course, we could implement our own DocumentLoader/ResourceLoader, >> and insure it always "gets" the proper Classloader...and change our >> application code to create XMLC Java objects by explicitly using >> constructor with DocumentLoader....but it seems to me a lot of >> unnecessary changes to the applications developed on top of XMLC, and >> used with XMLC "sitting" in shared classloader. >> >> Am I missing something this time as well? >> >> Greetings, >> Sasa. >> >> On 29-Mar-11 12:20, Sasa Bojanic wrote: >>> Back to the classloader issue...let me try to explain...you can >>> probably produce the same problem when you have TWO web apps with >>> XMLC and when XMLC is loaded by Tomcat's SHARED classloader...the >>> one of the apps will not work. >>> >>> So, everything works fine when I have only ONE XMLC based >>> application, and XMLC (+xerces and other JAR files) are in Tomcat's >>> SHARED lib. >>> >>> However, when I have two applications, one of them is not working, >>> can't find XMLC resources within JAR files. >>> >>> I investigated a bit, and this is what happens: >>> >>> 1) App1 starts, XMLCDeferredParsingFactory for this app is created >>> and is provided with Classloader1 (via >>> Thread.currentThread().getContextClassLoader()). >>> 2) App2 starts, XMLCDeferredParsingFactory for this app is created >>> and is provided with Classloader2 (via >>> Thread.currentThread().getContextClassLoader()). >>> (This is the change I've introduced in Enhydra Framework to test >>> this scenario - to use >>> Thread.currentThread().getContextClassLoader() instead of our >>> MultiClassLoader) >>> 3) When I use App1 (Calculator app), the following code is being >>> executed: >>> >>> calculator = >>> (CalculatorHTML)comms.xmlcFactory.create(CalculatorHTML.class); >>> >>> Then I trace: >>> >>> - XMLCDeferredParsingFactory that starts to create CalculatorHTML >>> object (XMLC class generated from HTML template) is the right one >>> for App1 >>> - create(Class) method from XMLCDeferredParsingFactory calls >>> doCreate(Class) and then createObject(Class) methods on the RIGHT >>> XMLCDeferredParsingFactory for App1 (calculator) >>> - In createObject(Class) method, reflection is used to create a new >>> instance of CalculatorHTML object: >>> >>> Constructor constructor = >>> xmlcBasedClass.getConstructor(CONSTRUCTOR_ARG_TYPES); >>> return >>> (XMLObject)constructor.newInstance(fConstructorArgs); >>> >>> - The constructor argument for generated XMLC class (CalculatorHTML >>> in this case) is a DocumentLoader (in my case a singleton instance >>> of StandardDocumentLoader) >>> - The constructor gets executed, and the method buildDocument() is >>> called >>> - buildDocument() method obtains DocumentLoader provided while >>> constructing the object and calls getDocument() method, which calls >>> getCacheEntry() method, which calls findSourceUrl() method...and >>> here I get an exception: >>> >>> org.enhydra.xml.xmlc.XMLCRuntimeException: Source path(s) >>> '[calculator/presentation/Calculator.html]' not found for >>> calculator.presentation.CalculatorHTML >>> >>> What actually happens here is that findSourceUrl() calls >>> ResourceLoaderImpl: >>> getResource()->getPathURLFromResourceDirOrClassPath(), and then >>> XMLCDeferredParsingFactory.getPathURLFromClasspath() method is >>> called (The one I first patched in my first post...but in the case >>> when I used our MultiClassLoader). >>> >>> The point is this XMLCDeferredParsingFactory is the one from App2, >>> and thus is the classloader it is using. >>> >>> The dump stack to explain what I described above: >>> java.lang.Exception: Stack trace >>> at java.lang.Thread.dumpStack(Thread.java:1206) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.getPathURLFromClasspath(XMLCDeferredParsingFactory.java:736) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getPathURLFromClasspath(ResourceLoaderImpl.java:101) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getPathURLFromResourceDirOrClasspath(ResourceLoaderImpl.java:80) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getResource(ResourceLoaderImpl.java:52) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.findSourceUrl(DocumentLoaderImpl.java:297) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getCacheEntry(DocumentLoaderImpl.java:174) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getDocument(DocumentLoaderImpl.java:247) >>> at >>> calculator.presentation.CalculatorHTML.buildDocument(CalculatorHTML.java:112) >>> at >>> calculator.presentation.CalculatorHTML.<init>(CalculatorHTML.java:92) >>> at >>> calculator.presentation.CalculatorHTML.<init>(CalculatorHTML.java:104) >>> at >>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) >>> at >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) >>> at >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) >>> at >>> java.lang.reflect.Constructor.newInstance(Constructor.java:513) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.createObject(XMLCDeferredParsingFactory.java:163) >>> at >>> org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.doCreate(XMLCDeferredParsingFactory.java:188) >>> at >>> org.enhydra.xml.xmlc.XMLCStdFactory.create(XMLCStdFactory.java:139) >>> at >>> calculator.presentation.CalculatorPresentation.getState(CalculatorPresentation.java:209) >>> at >>> calculator.presentation.CalculatorPresentation.run(CalculatorPresentation.java:49) >>> at >>> com.lutris.appserver.server.httpPresentation.HttpPresentationManager.runPresentationObj(HttpPresentationManager.java:496) >>> at >>> com.lutris.appserver.server.httpPresentation.HttpPresentationManager.Run(HttpPresentationManager.java:269) >>> at >>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.serviceDirect(HttpPresentationServlet.java:677) >>> at >>> com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.service(HttpPresentationServlet.java:787) >>> 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:619) >>> SRC URL=null >>> >>> >>> The reason for this is in the constructor of >>> XMLCDeferredParsingFactory: >>> >>> public XMLCDeferredParsingFactory(DocumentLoader docLoader, >>> ClassLoader classLoader, >>> XMLCLogger logger) { >>> super(classLoader, logger); >>> if (docLoader == null) { >>> docLoader = new StandardDocumentLoader(); >>> } >>> fConstructorArgs = new Object[] { docLoader }; >>> fDocLoader = docLoader; >>> fDynamicClassLoader = new DynamicClassLoader(classLoader, >>> logger); >>> // Initialize the document loader... >>> * fDocLoader.init(this);* >>> } >>> >>> The SINGLETON StandardDocumentLoader is initialized with the LAST >>> XMLCDeferredParsingFactory, and thus always taking the LAST APPs' >>> classloader (Thread.currentThread().getContextClassLoader() of the >>> application that was last initialized). >>> >>> And that is why the resource can't be found. The classloader of the >>> 2nd app can't find the resource of the 1st one. >>> >>> The point is that in the past our MultiClassLoader was "somehow" >>> handling that situations, and we were always passing this >>> classloader (instead of >>> Thread.currentThread().getContextClassLoader()) to every XMLC based >>> application, but for some reason (Tomcat bug or bug in our >>> MultiClassLoader in the combination with the changes in XMLC) it >>> does not work any more. >>> >>> Just wanted to report this...maybe it could also help you to see the >>> possible usage scenarios of XMLC (when many WEB applications are >>> sharing the XMLC classes instead of each of them loading it >>> separately), and the issues raised in that case. >>> >>> Greetings, >>> Sasa. >>> >>> On 29-Mar-11 08:02, Sasa Bojanic wrote: >>>> When I change the code as you suggested, the problem disappears. >>>> >>>> I assume there is nothing to report to NEKOHTML then? >>>> >>>> Thanks, >>>> 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. >>>>>>>>>>>>>>>>>>> >>>> >>> >> > ------------=_1301429511-30467-16177 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 ------------=_1301429511-30467-16177--