[xmlc] Re: Re: Re: Re: Issues with XMLC 2.3.2
Sasa Bojanic <[email protected]> Tue, 29 Mar 2011 12:20:45 +0200
| Newsgroups | gmane.comp.java.enhydra.xmlc |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format...
------------=_1301394059-30467-16120
Content-Type: multipart/alternative;
boundary="------------020901060605040802070005"
This is a multi-part message in MIME format.
--------------020901060605040802070005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.
>>>>>>>>>>>>>>>>
>
--------------020901060605040802070005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
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.<br>
<br>
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.<br>
<br>
However, when I have two applications, one of them is not working,
can't find XMLC resources within JAR files.<br>
<br>
I investigated a bit, and this is what happens:<br>
<br>
1) App1 starts, XMLCDeferredParsingFactory for this app is created
and is provided with Classloader1 (via
Thread.currentThread().getContextClassLoader()).<br>
2) App2 starts, XMLCDeferredParsingFactory for this app is created
and is provided with Classloader2 (via
Thread.currentThread().getContextClassLoader()).<br>
(This is the change I've introduced in Enhydra Framework to test
this scenario - to use
Thread.currentThread().getContextClassLoader() instead of our
MultiClassLoader)<br>
3) When I use App1 (Calculator app), the following code is being
executed:<br>
<br>
calculator =
(CalculatorHTML)comms.xmlcFactory.create(CalculatorHTML.class); <br>
<br>
Then I trace:<br>
<br>
- XMLCDeferredParsingFactory that starts to create CalculatorHTML
object (XMLC class generated from HTML template) is the right one
for App1<br>
- create(Class) method from XMLCDeferredParsingFactory calls
doCreate(Class) and then createObject(Class) methods on the RIGHT
XMLCDeferredParsingFactory for App1 (calculator)<br>
- In createObject(Class) method, reflection is used to create a new
instance of CalculatorHTML object:<br>
<br>
Constructor constructor =
xmlcBasedClass.getConstructor(CONSTRUCTOR_ARG_TYPES);<br>
return
(XMLObject)constructor.newInstance(fConstructorArgs);<br>
<br>
- The constructor argument for generated XMLC class (CalculatorHTML
in this case) is a DocumentLoader (in my case a singleton instance
of StandardDocumentLoader) <br>
- The constructor gets executed, and the method buildDocument() is
called<br>
- 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:<br>
<br>
org.enhydra.xml.xmlc.XMLCRuntimeException: Source path(s)
'[calculator/presentation/Calculator.html]' not found for
calculator.presentation.CalculatorHTML<br>
<br>
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).<br>
<br>
The point is this XMLCDeferredParsingFactory is the one from App2,
and thus is the classloader it is using.<br>
<br>
The dump stack to explain what I described above:<br>
java.lang.Exception: Stack trace<br>
at java.lang.Thread.dumpStack(Thread.java:1206)<br>
at
org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.getPathURLFromClasspath(XMLCDeferredParsingFactory.java:736)<br>
at
org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getPathURLFromClasspath(ResourceLoaderImpl.java:101)<br>
at
org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getPathURLFromResourceDirOrClasspath(ResourceLoaderImpl.java:80)<br>
at
org.enhydra.xml.xmlc.deferredparsing.ResourceLoaderImpl.getResource(ResourceLoaderImpl.java:52)<br>
at
org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.findSourceUrl(DocumentLoaderImpl.java:297)<br>
at
org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getCacheEntry(DocumentLoaderImpl.java:174)<br>
at
org.enhydra.xml.xmlc.deferredparsing.DocumentLoaderImpl.getDocument(DocumentLoaderImpl.java:247)<br>
at
calculator.presentation.CalculatorHTML.buildDocument(CalculatorHTML.java:112)<br>
at
calculator.presentation.CalculatorHTML.<init>(CalculatorHTML.java:92)<br>
at
calculator.presentation.CalculatorHTML.<init>(CalculatorHTML.java:104)<br>
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)<br>
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)<br>
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)<br>
at
java.lang.reflect.Constructor.newInstance(Constructor.java:513)<br>
at
org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.createObject(XMLCDeferredParsingFactory.java:163)<br>
at
org.enhydra.xml.xmlc.deferredparsing.XMLCDeferredParsingFactory.doCreate(XMLCDeferredParsingFactory.java:188)<br>
at
org.enhydra.xml.xmlc.XMLCStdFactory.create(XMLCStdFactory.java:139)<br>
at
calculator.presentation.CalculatorPresentation.getState(CalculatorPresentation.java:209)<br>
at
calculator.presentation.CalculatorPresentation.run(CalculatorPresentation.java:49)<br>
at
com.lutris.appserver.server.httpPresentation.HttpPresentationManager.runPresentationObj(HttpPresentationManager.java:496)<br>
at
com.lutris.appserver.server.httpPresentation.HttpPresentationManager.Run(HttpPresentationManager.java:269)<br>
at
com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.serviceDirect(HttpPresentationServlet.java:677)<br>
at
com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.service(HttpPresentationServlet.java:787)<br>
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)<br>
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)<br>
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)<br>
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)<br>
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)<br>
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)<br>
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)<br>
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)<br>
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)<br>
at
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861)<br>
at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)<br>
at
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)<br>
at java.lang.Thread.run(Thread.java:619)<br>
SRC URL=null<br>
<br>
<br>
The reason for this is in the constructor of
XMLCDeferredParsingFactory:<br>
<br>
public XMLCDeferredParsingFactory(DocumentLoader docLoader,<br>
ClassLoader classLoader,<br>
XMLCLogger logger) {<br>
super(classLoader, logger);<br>
if (docLoader == null) {<br>
docLoader = new StandardDocumentLoader();<br>
}<br>
fConstructorArgs = new Object[] { docLoader };<br>
fDocLoader = docLoader;<br>
fDynamicClassLoader = new DynamicClassLoader(classLoader,
logger);<br>
// Initialize the document loader...<br>
<b> fDocLoader.init(this);</b><br>
}<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Greetings,<br>
Sasa.<br>
<br>
On 29-Mar-11 08:02, Sasa Bojanic wrote:
<blockquote cite="mid:[email protected]" type="cite">When I
change the code as you suggested, the problem disappears.
<br>
<br>
I assume there is nothing to report to NEKOHTML then?
<br>
<br>
Thanks,
<br>
Sasa.
<br>
<br>
On 29-Mar-11 08:51, Jacob Kjome wrote:
<br>
<blockquote type="cite">I suspect nekohtml is manipulating the
table in ways you didn't expect. Check out
<br>
this from the 1.9.13 release note [1]...
<br>
<br>
"automatically add TBODY around TR nested directly within TABLE"
<br>
<br>
You say your code is...
<br>
<br>
table.removeChild(page.getElementTemplateRow());
<br>
<br>
But if nekohtml is adding a TBODY node around TR, then TR is not
a child of TABLE,
<br>
but TBODY, which could very well explain the error you are
seeing. It seems to me
<br>
that safer code would be...
<br>
<br>
page.getElementTemplateRow().getParentNode().removeChild(page.getElementTemplateRow());
<br>
<br>
<br>
Can you try that and let me know if the issue goes away with
nekohtml version
<br>
1.9.13 or later?
<br>
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://nekohtml.sourceforge.net/changes.html">http://nekohtml.sourceforge.net/changes.html</a>
<br>
<br>
Jake
<br>
<br>
On 3/29/2011 12:06 AM, Jacob Kjome wrote:
<br>
<blockquote type="cite">I've narrowed down the DOMException
NOT_FOUND_ERR problem to nekohtml. When I use
<br>
version 1.9.8, which is distributed with XMLC 2.3.1,
everything works fine, even
<br>
with XMLC 2.3.2. But when I use version 1.9.14, I get the
error you reported,
<br>
even with XMLC 2.3.1.
<br>
<br>
I backtracked through the versions of nekohtml to find the
latest version that
<br>
would work. I discovered that version 1.9.12 works fine, but
1.9.13 fails. So,
<br>
something introduced in 1.9.13 is causing the problem. I'll
try to do some more
<br>
digging this week to figure out what the root cause is. It
would be great if you
<br>
could do the same. When we can pinpoint the issue, we can
report it as a bug in
<br>
the nekohtml sourceforge project [1].
<br>
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://sourceforge.net/projects/nekohtml/">http://sourceforge.net/projects/nekohtml/</a>
<br>
<br>
<br>
Jake
<br>
<br>
On 3/28/2011 2:28 PM, Sasa Bojanic wrote:
<br>
<blockquote type="cite">My mistake about the "general"
problem...now I see that generated XMLC
<br>
Java classes have non-default constructor taking
DocumentLoader object
<br>
as an initialization parameter...sorry.
<br>
<br>
I still hesitate to contact Tomcat guys since I'm not deep
into our
<br>
MultiClassLoader code...so I don't know if there is a bug
in-there.
<br>
<br>
Regarding DOM problem, yes, I tried both XERCES/XML-APIS
from XMLC2.3-1
<br>
and XMLC2.3-2, and the result is the same.
<br>
<br>
"projectManagement" application and ALL other applications
from the ZIP
<br>
file:
<br>
<a class="moz-txt-link-freetext" href="https://docs.google.com/leaf?id=0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=name&layout=list&pid=0B9ZAe6ftekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=18">https://docs.google.com/leaf?id=0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=name&layout=list&pid=0B9ZAe6ftekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=18</a>
<br>
<br>
<br>
are prepared for Stand-alone Tomcat deployment...
<br>
<br>
Greetings,
<br>
Sasa.
<br>
<br>
On 28-Mar-11 22:04, Jacob Kjome wrote:
<br>
<blockquote type="cite">See comments inline below...
<br>
<br>
On Mon, 28 Mar 2011 14:35:27 +0200
<br>
Sasa Bojanic<a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a> wrote:
<br>
<blockquote type="cite">Jake, first of all, thanks a lot
for your effort!
<br>
<br>
</blockquote>
No problem. I any changes I made are breaking
applications, I want to
<br>
make sure they get corrected, or at least explained,
properly.
<br>
<br>
<blockquote type="cite">...here is the followup:
<br>
<br>
1) I think there is a general problem in XMLC when
implementing
<br>
CustomDocumentLoader/CustomResourceLoader.
<br>
Hence, the JAVA classes generated based on HTML template
always use
<br>
StandardDocumentLoader.
<br>
</blockquote>
I'm not sure I understand how this is a "general problem"
with
<br>
document/resource loaders. Keep in mind, they are
resource location
<br>
generic, i.e., they are meant to make resource loading
plugable,
<br>
allowing loading from contexts not possible prior to XMLC
2.3.2, such
<br>
as the servlet context... or even a database. Loading
from a class
<br>
loader is merely one option, albeit a built-in default one
as it has
<br>
been available (along with loading from configured
resource
<br>
directories) since the original XMLC 2.2 release. The
custom one I
<br>
created for you is a minimal implementation that simply
overrides the
<br>
way URLs are obtained from the class loader in the default
resource
<br>
loader implementation.
<br>
<br>
In my view, this is clearly a class loader bug. If the
class loader
<br>
can actually see the resource and provide a URL, then that
URL ought
<br>
to be a valid one. That Tomcat's StandardClassLoader is
returning an
<br>
invalid URL is absolutely a bug that should be reported
to, and
<br>
corrected by, the Tomcat team. Supplying the thread
context class
<br>
loader to the XMLCDeferredParsingFactory constructor is
the obvious
<br>
workaround. But it is a workaround only made necessary by
a class
<br>
loader bug.
<br>
<br>
That said, I recommend using the thread context class
loader
<br>
regardless of this particular class loader bug, as it
provides the
<br>
added benefit of allowing XMLC libraries in the server lib
to be able
<br>
to see classes and resources in a child classloader (e.g,
the
<br>
WebappClassLoader).
<br>
<br>
<blockquote type="cite">Don't know if this can be somehow
configured to specify the custom
<br>
one? options.xmlc?
<br>
<br>
</blockquote>
I really view this as outside the scope of XMLC
configuration. That
<br>
configuration is focused on template configuration, not
how they are
<br>
loaded. Besides, the resource loader is used to load
options.xmlc.
<br>
It's a chicken/egg problem. Application code has complete
control
<br>
over how the XMLCDeferredParsingFactory is instantiated,
so it is
<br>
application code where this should be addressed.
<br>
<br>
XMLCContext, if you so choose to use it, provides for
various servlet
<br>
context parameters that you can configure in web.xml to
specify
<br>
various things, including document loaders. And it
**ALWAYS**
<br>
instantiates the XMLCDeferredParsingFactory using the
thread context
<br>
class loader. See....
<br>
<br>
<a class="moz-txt-link-freetext" href="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%2Fres%2Fwebapps%2Fxmlc%2FWEB-INF%2Fweb.xml.in</a>
<br>
<br>
<br>
<a class="moz-txt-link-freetext" href="http://websvn.ow2.org/filedetails.php?repname=xmlc&path=%2Ftrunk%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FPreview.java">http://websvn.ow2.org/filedetails.php?repname=xmlc&path=%2Ftrunk%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FPreview.java</a>
<br>
<br>
<br>
<br>
All you need to do to access it is...
<br>
<br>
XMLCContext context = XMLCContext.getContext(servletObj);
<br>
...or...
<br>
XMLCContext context =
XMLCContext.getContext(servletContextObj);
<br>
<br>
...and then...
<br>
XMLCDeferredParsingFactory dpFactory =
<br>
context.getXMLCDeferredParsingFactory();
<br>
<br>
<br>
If you use this, your applications will be more
configurable and never
<br>
run into invalid URLs again.
<br>
<br>
<br>
<blockquote type="cite">2) Maybe it makes sense to
implement the following patch to XMLC's
<br>
ResourceLoaderImpl:
<br>
<br>
protected URL getPathURLFromClasspath(final String
candidatePath) {
<br>
URL url =
<br>
Thread.currentThread().getContextClassLoader().getResource(candidatePath);
<br>
<br>
if (url==null) {
<br>
url =
fFactory.getPathURLFromClasspath(candidatePath);
<br>
}
<br>
return url;
<br>
}
<br>
<br>
</blockquote>
Actually, it would be the thread context classloader that
might be
<br>
null, in the case that the code is not running under a JEE
server that
<br>
sets it. That said, it's an option to consider, e.g.,....
<br>
<br>
protected URL getPathURLFromClasspath(final String
candidatePath) {
<br>
ClassLoader loader =
<br>
Thread.currentThread().getContextClassLoader();
<br>
if (loader != null) {
<br>
return loader..getResource(candidatePath);
<br>
}
<br>
return
fFactory.getPathURLFromClasspath(candidatePath);
<br>
}
<br>
<br>
But while this might transparently resolve your issue, it
takes away
<br>
the ability of the user to determine the class loader to
use, which
<br>
they can currently specify by supplying their class loader
of choice
<br>
to the XMLCDeferredParsingFactory constructor. For this
reason, I
<br>
hesitate to implement this option.
<br>
<br>
<br>
<blockquote type="cite">3) I found the place where we can
patch Enhydra's MultiClassLoader
<br>
(similar way as the patch provided for
XMLCDeferredParsingFactory),
<br>
so that it returns the "right" resource path in the case
of JAR
<br>
files, so actually from our side, there is no need for
the
<br>
modification mentioned above.
<br>
</blockquote>
I take it your class loader wraps Tomcat's
StandardClassLoader (when
<br>
running under Tomcat, that is)? Maybe you should have it
wrap the
<br>
thread context class loader instead? That way, you avoid
the
<br>
StandardClassLoader's buggyness. In any case, there's no
good reason
<br>
for any class loader to return invalid URLs. Again, I
urge you to
<br>
report this issue to the Tomcat developers so this issue
can be
<br>
properly fixed for everyone using Tomcat's
StandardClassLoader.
<br>
<br>
<blockquote type="cite">4) When implementing either the
modification on ResourceLoaderImpl or
<br>
changing MultiClassLoader, calculator and discRack
applications are
<br>
working normally. However, the projectManagement
application is
<br>
working only "partially"...maybe it is a completely new
problem
<br>
there, or this is the similar one but somehow hidden and
not so
<br>
obvious to determine (just to mention that application
works normally
<br>
under EXACTLY THE SAME conditions under XMLC2.3-1).
<br>
The start page of projectManagement applications is
generated
<br>
smoothly, when you log in as admin/enhydra, the next
page is also OK.
<br>
However, when you click on the link "Employee" or
"Customer", the
<br>
following exception is thrown:
<br>
<br>
</blockquote>
This is a completely distinct problem. This is either an
issue with
<br>
the LazyDOM or, possibly with Xerces itself. Did you try
downgrading
<br>
to the version of xercesImpl and xml-apis that came with
XMLC-2.3.1?
<br>
Please try that first. If you still get an error, let me
know. I
<br>
think there was a change to the lazydom for XMLC 2.3.2
(some bug
<br>
fix). I can't recall exactly what it was, though. It's
possible I
<br>
introduced a regression. Only more testing will tell.
<br>
<br>
BTW, is the "projectManagement" application runnable under
<br>
Tomcat-Standalone or does it require Enhydra server?
<br>
<br>
<blockquote type="cite">org.w3c.dom.DOMException:
NOT_FOUND_ERR: An attempt is made to
<br>
reference a node in a context where it does not exist.
<br>
at
<br>
org.apache.xerces.dom.ParentNode.internalRemoveChild(Unknown
Source)
<br>
at
org.apache.xerces.dom.ParentNode.removeChild(Unknown
Source)
<br>
at
<br>
org.enhydra.xml.lazydom.LazyElementNoNS.removeChild(LazyElementNoNS.java:338)
<br>
<br>
at
<br>
projectmanagement.presentation.employees.Administering.handleDefault(Administering.java:80)
<br>
<br>
at
<br>
projectmanagement.presentation.BasePO.handleEvent(BasePO.java:282)
<br>
at
projectmanagement.presentation.BasePO.run(BasePO.java:156)
<br>
at
<br>
com.lutris.appserver.server.httpPresentation.HttpPresentationManager.runPresentationObj(Unknown
<br>
Source)
<br>
at
<br>
com.lutris.appserver.server.httpPresentation.HttpPresentationManager.Run(Unknown
<br>
Source)
<br>
at
<br>
com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.serviceDirect(HttpPresentationServlet.java:697)
<br>
<br>
at
<br>
com.lutris.appserver.server.httpPresentation.servlet.HttpPresentationServlet.service(HttpPresentationServlet.java:822)
<br>
<br>
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
<br>
at
<br>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
<br>
<br>
at
<br>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
<br>
<br>
at
<br>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
<br>
<br>
at
<br>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
<br>
<br>
at
<br>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
<br>
<br>
at
<br>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
<br>
<br>
at
<br>
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
<br>
<br>
at
<br>
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
<br>
<br>
at
<br>
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861)
<br>
<br>
at
<br>
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)
<br>
<br>
at
<br>
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)
<br>
at java.lang.Thread.run(Thread.java:662)
<br>
<br>
<br>
(I just modified a little bit original sources to print
the stack
<br>
trace of the exception).
<br>
<br>
table.removeChild(page.getElementTemplateRow());
<br>
<br>
The strange is that such exception does not happen when
accessing
<br>
Project/Pay Rate/Worksheet links, and the code for this
pages is
<br>
similar...removal of table template row happens.
<br>
<br>
Can you give me some leads here?
<br>
<br>
</blockquote>
See above for answers.
<br>
<br>
<blockquote type="cite">Greetings,
<br>
Sasa.
<br>
<br>
</blockquote>
<br>
Jake
<br>
<br>
<blockquote type="cite">On 28-Mar-11 07:11, Jacob Kjome
wrote:
<br>
<blockquote type="cite">I tried out your calculator.war
example and was able to replicate
<br>
the problem.
<br>
I've also tracked down the cause. It turns out that
while XMLC
<br>
2.3.1 and 2.3.2
<br>
still do essentially the same thing, there's a nuance
in how source
<br>
file URLs are
<br>
created. In XMLC 2.3.1, the classloader used to
obtain the URL is
<br>
the same one
<br>
that loaded the XMLC class file. In XMLC 2.3.2, it's
the one
<br>
provided to the
<br>
XMLCDeferredParsingFactory constructor.
<br>
<br>
Now, in the Tomcat demo application, this turns out to
be the same
<br>
classloader, as
<br>
XMLCContext provides
<br>
"Thread.currentThread().getContextClassLoader()" to
the
<br>
XMLCDeferredParsingFactory constructor and, of course,
this ends up
<br>
being the
<br>
WebappClassLoader as it's a thread from the current
application that
<br>
is loading
<br>
all the classes and the server sets this as the thread
context class
<br>
loader for us.
<br>
<br>
As it turns out, when URLs are created from the
WebappClassLoader,
<br>
loader.toString(), or loader.toExternalForm(),
produces a valid JAR
<br>
URL, such as...
<br>
<br>
<a class="moz-txt-link-freetext" href="jar:file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/WEB-INF/lib/calculator.jar!/calculator/presentation/Calculator.html">jar:file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/WEB-INF/lib/calculator.jar!/calculator/presentation/Calculator.html</a>
<br>
<br>
<br>
However, in the calculator application, the
classloader provided to the
<br>
XMLCDeferredParsingFactory constructor is actually the
parent
<br>
classloder of the
<br>
WebappClassLoader and, under Tomcat Standalone, an
instance of
<br>
"org.apache.catalina.loader.StandardClassLoader".
<br>
<br>
As it turns out, when URLs are created from the
StandardClassLoader,
<br>
loader.toString(), or loader.toExternalForm(),
produces an invalid
<br>
JAR URL, such as...
<br>
<br>
<a class="moz-txt-link-freetext" href="file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/WEB-INF/lib/calculator.jarcalculator/presentation/Calculator.html">file:/E:/Java/Apache/apache-tomcat-7.0.11/webapps/calculator/WEB-INF/lib/calculator.jarcalculator/presentation/Calculator.html</a>
<br>
<br>
<br>
<br>
This subtle change in behavior was unforeseen and you
are the first
<br>
to report it.
<br>
I never encountered it in my testing because, as
mentioned
<br>
previously, I always
<br>
use the thread context class loader. Personally, I
think it's a bug
<br>
in Tomcat, as
<br>
it shouldn't matter what kind of class loader it is.
All class
<br>
loaders ought to
<br>
be able to generate valid jar URLs. I encourage you
to report this
<br>
to the Tomcat
<br>
development team!
<br>
<br>
At this point, there's no going back to the way XMLC
2.3.1 loaded
<br>
URLs because of
<br>
significant design changes. The point at which URLs
are now loaded
<br>
provides no
<br>
access to the XMLC class file and, therefore, no way
to obtain the
<br>
classloader
<br>
that loaded the XMLC class file... that is, unless
XMLC always uses
<br>
the thread
<br>
context classloader to load resources (more on that
below). Anyway,
<br>
here are the
<br>
obvious fixes in my order of preference...
<br>
<br>
1. Always pass
"Thread.currentThread().getContextClassLoader()" to
the
<br>
XMLCDeferredParsingFactory constructor. This resolves
all issues,
<br>
end of story.
<br>
<br>
2. If #1 is not possible/desirable, then you can
implement your own
<br>
custom
<br>
document/resource loader, similar to what I attached
to my last
<br>
email (see the new
<br>
version attached to this email); the only difference
being the
<br>
method to override
<br>
now looks like...
<br>
<br>
protected URL getPathURLFromClasspath(final
String
<br>
candidatePath) {
<br>
return
<br>
Thread.currentThread().getContextClassLoader().getResource(candidatePath);
<br>
<br>
}
<br>
<br>
3. Change XMLC's
<br>
XMLCDeferredParsingFactory.getPathURLFromClasspath(String)
<br>
method to use the thread context classloader. While
this is an
<br>
option, it's not a
<br>
very good one because the thread context class loader
may not always
<br>
be the right
<br>
choice. While it generally is the right choice
99.99999% of the
<br>
time in a JEE
<br>
environment, XMLC is not always used in a server
environment. And
<br>
there's always
<br>
going to be that edge case where, even in a server
environment it's
<br>
not desirable.
<br>
And, of course, that's where option #1 really
shines. You get to
<br>
choose which
<br>
classloader to use so XMLC doesn't have to guess.
<br>
<br>
4. If you can think of a better idea, let me know.
I'm highly
<br>
resistant to #3.
<br>
I realize the change in behavior is inconvenient (and
most likely a
<br>
Tomcat bug
<br>
anyway), but it's a simple change on the user's part
and can be done
<br>
as part of
<br>
the upgrade from 2.3.1 to 2.3.2. Besides, the design
changes that
<br>
introduced this
<br>
[easily-worked-around] situation make XMLC far more
flexible in
<br>
regard to resource
<br>
loading than it was before. I think the benefits
outweigh the costs.
<br>
<br>
<br>
Thoughts?
<br>
<br>
Jake
<br>
<br>
On 3/27/2011 3:56 PM, Sasa Bojanic wrote:
<br>
<blockquote type="cite">OK, as I said, I will try to
look at our classloader. But I can
<br>
confirm
<br>
that the problem that occurs with XMLC 2.3-2 does
NOT occur with XMLC
<br>
2.3-1 under EXACTLY the SAME conditions.
<br>
As a sample, this time I used the simplest
"calculator" application
<br>
from
<br>
Enhydra Demos package. This sample uses only XMLC
and Enhydra
<br>
Framework
<br>
classes (no database where we use our product DODS,
and then JOTM and
<br>
other JTA support libraries).
<br>
<br>
I deployed "calculator" application under pure
Tomcat 6.0-29, JDK
<br>
1.6.0_23 x64, Win7 x64.
<br>
It works normally. Then I first replaced xercesImpl,
xml-apis and
<br>
nekohtml JAR files with the newer versions from XMLC
2.3-2. It still
<br>
worked normally.
<br>
After I finally replaced xmlc.jar (2.3-1) with
xmlc-all-runtime.jar,
<br>
removed gnu-regexp.jar and introduced jregex.jar, I
get the 1st
<br>
described problem with not being able to find the
resource from the
<br>
JAR
<br>
file:
<br>
<br>
java.io.FileNotFoundException:
<br>
d:\apache-tomcat-6.0.29\webapps\calculator\WEB-INF\lib\calculator.jarcalculator\presentation\CalculatorHTML.xmlc
<br>
<br>
(The system cannot find the path specified)
<br>
<br>
You can download a set of Enhydra Demo applications
(version 8.4-1)
<br>
for
<br>
pure Tomcat from:
<br>
<br>
<a class="moz-txt-link-freetext" href="https://docs.google.com/leaf?id=0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=name&layout=list&pid=0B9ZAe6ftekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=18">https://docs.google.com/leaf?id=0B9ZAe6ftekYJMGVmYjdmZDMtMjY5YS00MDU4LWIzNWEtYzhiMjBlMzZjYTZj&sort=name&layout=list&pid=0B9ZAe6ftekYJNWQ0ZDRmNjMtN2M2MS00NDIyLWJmZmUtYWE0Y2Y4MDFiMDUw&cindex=18</a>
<br>
<br>
<br>
<br>
(If necessary, you can find the source code of
Enhydra Demos (TDA),
<br>
Enhydra Framework (TAF), Enhydra DODS (TRO) at:
<br>
<a class="moz-txt-link-freetext" href="https://docs.google.com/leaf?id=0B9ZAe6ftekYJNTc0OWM2NzctNzM3MS00YmNjLTkyMTctZjg0ZWUxZWI2YWQw&;hl=en">https://docs.google.com/leaf?id=0B9ZAe6ftekYJNTc0OWM2NzctNzM3MS00YmNjLTkyMTctZjg0ZWUxZWI2YWQw&;hl=en</a>
<br>
<br>
<br>
but to reproduce the problem, downloading the 1st
link is enough)
<br>
<br>
There are many applications based on XMLC included
in the ZIP file
<br>
from
<br>
the 1st link above, ready to be deployed on pure
Tomcat.
<br>
As the simplest one for testing you can take
"calculator.war" I used
<br>
this time.
<br>
<br>
After I provide a "patch/workaround" for this
problem of finding
<br>
resource in the JAR file, the problem disappears.
<br>
<br>
When I moved all the JAR files except the
application JAR file
<br>
(calculator.jar) to the common/shared class-loader
(Tomcat's lib
<br>
folder), this time I do NOT have the 2nd problem I
described...so that
<br>
might be my mistake during previous tests. The 2nd
problem also
<br>
does NOT
<br>
appear with "discRack" application either. So I
assume the
<br>
"patch/workaround" somehow solves all the problems.
<br>
<br>
Since the ONLY difference with the deployment of
this sample
<br>
XMLC/Enhydra Framework/DODS applications is the
version of XMLC,
<br>
can you
<br>
please look at that samples yourself, and confirm
the issue.
<br>
<br>
Greetings,
<br>
Sasa.
<br>
<br>
<br>
On 26-Mar-11 20:14, Jacob Kjome wrote:
<br>
<blockquote type="cite">The thing is, XMLC doesn't
create the URL object that provides the
<br>
path to the
<br>
resource; the classloader does. That goes for
both XMLC 2.3.1 and
<br>
2.3.2. I can't
<br>
explain why behavior would be different for you
between the two
<br>
versions? Of
<br>
course, I can't replicate your findings in the
first place, so I'm at
<br>
a loss.
<br>
<br>
One thing that is a red flag for me is the path
you provided...
<br>
<br>
"d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRack.jardiscRack*\presentation\ErrorHTML.xmlc"
<br>
<br>
<br>
<br>
That isn't even a valid URL. There's no <a class="moz-txt-link-rfc2396E" href="file:/">"file:/"</a>
and all the
<br>
slashes are
<br>
backward. This looks to me like a custom
classloader bug. Again,
<br>
XMLC doesn't
<br>
generate the URL, the classloader does.
<br>
<br>
When you say that "it works under 2.3.1", are you
sure you tested
<br>
2.3.1 with the
<br>
same version of the server you are using to test
2.3.2? That is,
<br>
when
<br>
you tested
<br>
2.3.1, was the server an older version than what
you are using with
<br>
2.3.2? If so,
<br>
please reduce the number of extraneous variables
by testing with the
<br>
older server
<br>
version (the one known to work) and just switching
out the 2.3.1
<br>
libraries with
<br>
the 2.3.2 libraries. Do you get better results?
<br>
<br>
If you can send me a minimal webapp (able to run
under Tomcat
<br>
standalone) with
<br>
explicit instructions on how to replicate the
problem, then I'll test
<br>
it myself
<br>
and let you know the results.
<br>
<br>
BTW, here's how XMLCContext loads up the deferred
parsing factory...
<br>
<br>
XMLCDeferredParsingFactory newFactory
<br>
= new
XMLCDeferredParsingFactory(loader,
<br>
Thread.currentThread().getContextClassLoader(),
logger);
<br>
<br>
<br>
First, notice that the classloader is set up as
the thread context
<br>
class loader of
<br>
the application. This is the reason why the XMLC
Tomcat demo
<br>
works no
<br>
matter
<br>
where the XMLC libraries are located in relation
to the jar
<br>
containing
<br>
the
<br>
templates. When templates are in the parent
classloader, the webapp
<br>
(child)
<br>
classloader can always see that, so they load just
fine. And when
<br>
the
<br>
templates
<br>
are in the webapp classloader while the XMLC
libraries are in the
<br>
parent, XMLC can
<br>
see down to the child classloader because it has a
reference to
<br>
the child
<br>
classloader via the thread context classloader.
<br>
<br>
Clearly the "(MultiClassLoader)
<br>
presentationManager.getAppClassLoader()" doesn't
<br>
have a reference to the thread context
classloader, otherwise you
<br>
would not run
<br>
into the issues you have of not finding the
templates in certain
<br>
situations.
<br>
<br>
<br>
Second, you can customize the loading of resources
by using a custom
<br>
DocumentLoader/ResourceLoader combo. See the
<br>
ValidatingDocumentLoader
<br>
example in
<br>
the Tomcat demo....
<br>
<br>
<a class="moz-txt-link-freetext" href="http://websvn.ow2.org/filedetails.php?repname=xmlc&path=%2Ftags%2FXMLC_2_3_2%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FValidatingDocumentLoader.java">http://websvn.ow2.org/filedetails.php?repname=xmlc&path=%2Ftags%2FXMLC_2_3_2%2Fxmlc%2Fexamples%2Ftomcat%2Fsrc%2Fxmlc%2Fdemo%2FValidatingDocumentLoader.java</a>
<br>
<br>
<br>
<br>
This one extends ServletDocumentLoaderImpl, but if
you don't care
<br>
about loading
<br>
resources from the servlet context, then you can
just extend
<br>
DocumentLoaderImpl.
<br>
Attached is a sample you can use. Instead of
using
<br>
StandardDocumentLoader.getInstance() in the
following...
<br>
<br>
xmlcFactory = new
<br>
XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
<br>
<br>
(MultiClassLoader)presentationManager.getAppClassLoader(),
<br>
new
EnhydraXMLCLogger(logChannel));
<br>
<br>
...use...
<br>
<br>
xmlcFactory = new XMLCDeferredParsingFactory(new
<br>
CustomDocumentLoader(),
<br>
<br>
(MultiClassLoader)presentationManager.getAppClassLoader(),
<br>
new
EnhydraXMLCLogger(logChannel));
<br>
<br>
...and if you want to be able to load resources no
matter where they
<br>
exist in the
<br>
classloader hierarchy relative to where XMLC
libraries exist in the
<br>
hierarchy use...
<br>
<br>
xmlcFactory = new XMLCDeferredParsingFactory(new
<br>
CustomDocumentLoader(),
<br>
<br>
Thread.currentThread().getContextClassLoader(),
<br>
new
EnhydraXMLCLogger(logChannel));
<br>
<br>
With the custom document/resource loader, you can
change the behavior
<br>
of resource
<br>
loading without modifying the internals of XMLC at
all. This feature
<br>
is new to
<br>
XMLC-2.3.2. However, remember that besides the
added plugability
<br>
provided by
<br>
XMLC-2.3.2, ultimately, XMLC 2.3.1 and 2.3.2 don't
do anything
<br>
different to load
<br>
resources from the classloader. They both use
<br>
classLoader.getResource("some/path/to/resoruce.html").
If that
<br>
provides a URL
<br>
producing an invalid path, that's a bug in the
classloader, not XMLC.
<br>
<br>
<br>
Jake
<br>
<br>
On 3/25/2011 9:14 AM, Sasa Bojanic wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
yes, I'm of course also using 64-bit Java.
<br>
<br>
I will check about our MultiClassLoader, but the
point is EVERYTHING
<br>
WORKS PERFECTLY with XMLC 2.3-1. We don't have a
problem with
<br>
resource
<br>
lookup within the JAR file, and do not have a
problem with scenario
<br>
where XMLC is not in the application's
classloader.
<br>
<br>
We are trying to find the reason why we can't
switch to XMLC 2.3-2
<br>
seamlessly...and since everything works with
XMLC2.3-1 we think
<br>
it is a
<br>
XMLC issue?
<br>
<br>
Regards,
<br>
Sasa.
<br>
<br>
On 25-Mar-11 16:03, Jacob Kjome wrote:
<br>
<blockquote type="cite">In this particular case,
XMLC can certainly find the file (as
<br>
opposed
<br>
to the other case where it can't when XMLC
libs are in the
<br>
server lib,
<br>
at least on your system), but the path is
messed up. But this is
<br>
really not XMLC's fault. The classloader's
getResource() method is
<br>
returning an invalid path. Other than
tweaking it with your
<br>
workaround, there's nothing XMLC can (nor
should) do about that
<br>
(though there is a way you can work around
this without messing
<br>
with
<br>
XMLC's core, which I will send in a separate
email later
<br>
today). As I
<br>
mentioned, it works perfectly well on my
system.
<br>
<br>
You have, potentially, at least 3 platform
differences. The
<br>
first is
<br>
Win7 x64, where I've only tested on WinXP
x32. You may also be
<br>
using
<br>
64 bit Java, though you'd have to verify
that. And you are running
<br>
under Enhydra, with some "MultiClassLoader"
classloader
<br>
implementation. Somewhere in these
differences lies a bug that
<br>
is not
<br>
the fault of XMLC.
<br>
<br>
I would start first with the "MultiClasLoader"
and see whether
<br>
there
<br>
is a bug in its getResource() method that
returns URL's with
<br>
invalid
<br>
paths when resources are looked up in jar
files. Second, I'd
<br>
check if
<br>
there's a bug in the JDK you are using (maybe
the 64 bit version
<br>
has a
<br>
bug where the 32 bit version I use does
not?). Third, I guess
<br>
could
<br>
be a bug in Win7, though I would think the
Java platform would be
<br>
responsible for working around that given the
supposed "platform
<br>
independence" and all.
<br>
<br>
Expect another email describing a workaround
you can use, without
<br>
messing with XMLC's core, a bit later when I
have access to my
<br>
development machine.
<br>
<br>
Jake
<br>
<br>
<br>
On Thu, 24 Mar 2011 22:41:23 +0100
<br>
Sasa Bojanic<a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>
wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
from what I can see in Enhydra code,
XMLCDeferredParsingFactory is
<br>
obtained by calling its constructor:
<br>
<br>
xmlcFactory = new
<br>
XMLCDeferredParsingFactory(StandardDocumentLoader.getInstance(),
<br>
<br>
(MultiClassLoader)
presentationManager.getAppClassLoader(),
<br>
new
<br>
EnhydraXMLCLogger(logChannel));
<br>
<br>
First of all let me show you an error that
occurs when XMLC is
<br>
in the
<br>
application classloader. The error is in the
attached document...
<br>
<br>
I use Tomcat 6.0.29, Java 1.6_23, Win7 x64,
and all the JARs
<br>
you've
<br>
mentioned are in this case in the
application's WEB-INF\lib
<br>
folder.
<br>
<br>
If you notice, the XMLC is reporting to
search for:
<br>
<br>
d:\apache-tomcat-6.0.29\webapps\discRack\WEB-INF\lib\*discRack.jardiscRack*\presentation\ErrorHTML.xmlc
<br>
<br>
<br>
<br>
<br>
When I "patch" XMLC as described before,
this scenario works well.
<br>
<br>
Regards,
<br>
Sasa.
<br>
<br>
On 21-Mar-11 00:34, Jacob Kjome wrote:
<br>
<blockquote type="cite">Hi Sasa,
<br>
<br>
I finally made some time to look into the
issues you reported.
<br>
Interestingly, I'm
<br>
not able to reproduce either issue. I
used Tomcat-6.0.29
<br>
standalone, as that's
<br>
the version you used (note that I did not
try Enhydra).
<br>
<br>
To test issue #1, I jar'ed up the classes
and markup files and
<br>
made
<br>
sure to rename
<br>
the resource dirs so files located there
could not be found.
<br>
I also
<br>
renamed the
<br>
WEB-INF/xmlc directory in the demo app to
ensure templates
<br>
could not
<br>
be loaded via
<br>
the servlet context (allowed for by the
custom
<br>
ValidatingDocumentLoader.ValidatingResourceLoader
class used
<br>
in the
<br>
xmlc tomcat
<br>
demo), thus could only be loaded via the
classloader. I
<br>
placed the
<br>
templates jar
<br>
in WEB-INF/lib and ran tomcat. First I
tried loading the
<br>
Welcome.html page
<br>
(french locale, because that's what I had
selected in the tomcat
<br>
demo), which came
<br>
up fine. I took a look at the log to see
how the file was
<br>
loaded...
<br>
<br>
INFO:>>>Parsing DOM for
$$XMLC_GENERATED$$.xmlc.demo.Welcome.html
<br>
from source URL
<br>
<a class="moz-txt-link-freetext" href="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">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</a>
<br>
<br>
<br>
<br>
<br>
...so, clearly it is being loaded via the
classloader... and
<br>
working
<br>
fine for me.
<br>
<br>
<br>
To test issue #2, I copied the following
jars into
<br>
${catalina.base}/shared...
<br>
<br>
jregex.jar
<br>
nekohtml.jar
<br>
resolver.jar
<br>
xercesImpl.jar
<br>
xml-apis.jar
<br>
xmlc-all-runtime.jar
<br>
<br>
Note that the Tomcat demo has a modified
<br>
${catalina.base}/conf/catalina.properties,
which places the
<br>
${catalina.base}/shared directory, as well
as contained jars,
<br>
in the
<br>
common
<br>
loader. It looks like...
<br>
<br>
common.loader=${catalina.base}/shared,${catalina.base}/shared/*.jar,${catalina.home}/shared,${catalina.home}/shared/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar
<br>
<br>
<br>
<br>
<br>
This would be no different than putting
the jars in
<br>
${catalina.home}/lib, but
<br>
avoids having to muck with the contents of
the stock Tomcat
<br>
installation.
<br>
<br>
Anyway, I left my jar file containing the
XMLC classes and
<br>
templates in
<br>
WEB-INF/lib. Again I tried loading the
Welcome.html page and,
<br>
again, it came up
<br>
fine. I looked at the log and the INFO
message was the same as
<br>
above. I then
<br>
moved the templates jar file to the
${catalina.base}/shared
<br>
directory and tried it
<br>
again. The page came up fine and the INFO
message looked like...
<br>
<br>
INFO:>>>Parsing DOM for
$$XMLC_GENERATED$$.xmlc.demo.Welcome.html
<br>
from source URL
<br>
<a class="moz-txt-link-freetext" href="jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/tomcat/build/shared/xmlc-templates.jar!/demo/Welcome_fr.html">jar:file:/D:/dev/XMLC_FORGE_SVN/tags/XMLC_2_3_2/xmlc/examples/tomcat/build/shared/xmlc-templates.jar!/demo/Welcome_fr.html</a>
<br>
<br>
<br>
<br>
<br>
<br>
I'm not sure what to tell you? It all
works fine for me. Note
<br>
that my
<br>
environment consists of...
<br>
<br>
Windows XP sp3
<br>
Java 1.6.0_24
<br>
Tomcat-6.0.29 (standalone run from the
command line)
<br>
<br>
<br>
Note that I use XMLCContext to obtain the
<br>
XMLCDeferredParsingFactory.
<br>
<br>
<br>
At this point, I can only say that it
works for me. Maybe the
<br>
it's
<br>
platform
<br>
differences that are causing issues? What
OS and version of
<br>
Java do
<br>
you use?
<br>
What does the original "jar:" URL look
like when you run it
<br>
(prior
<br>
to having to
<br>
muck with it to get it to work in your
environment)? And
<br>
please let
<br>
me know how
<br>
you obtain the XMLCDeferredParsingFactory.
<br>
<br>
<br>
Jake
<br>
<br>
<br>
On 3/7/2011 1:46 PM, Sasa Bojanic wrote:
<br>
<blockquote type="cite">Well, it is not
really a patch, but something that made
my
<br>
use case
<br>
one
<br>
working...I agree nowdays it would be
reasonable to move XMLC to
<br>
JDK1.5
<br>
or even 1.6...
<br>
<br>
Thanks a lot for the quick response!
<br>
<br>
Sasa.
<br>
<br>
<br>
On 07-Mar-11 17:13, Jacob Kjome wrote:
<br>
<blockquote type="cite">I can look into
using your patch for #1 (or something
like
<br>
it) for
<br>
the
<br>
next XML release. I think the primary
issue here is that we've
<br>
maintained a dependency on JDK1.3,
which does not have
<br>
java.net.URI.
<br>
I've tried to maintain this minimum
dependency as long as
<br>
Xerces
<br>
does
<br>
so. Plus it makes for easy testing
because JDK1.3 doesn't add
<br>
any of
<br>
its own XML libraries. It's easy to
dictate the version
<br>
without
<br>
getting buggy JDK1.4 XML behavior.
But I think most of the
<br>
world has
<br>
moved on to JDK1.5+, so maybe XMLC
should too at some point?
<br>
<br>
I'll have to test #2. Not sure how
quickly I'll be able to
<br>
get to
<br>
this, though. But I'll try and spend
some time this week on
<br>
it.
<br>
<br>
Jake
<br>
<br>
On Mon, 07 Mar 2011 13:56:15 +0100
<br>
Sasa
Bojanic<a class="moz-txt-link-rfc2396E" href="mailto:[email protected]"><[email protected]></a>
wrote:
<br>
<blockquote type="cite">Hi,
<br>
<br>
I'm trying to upgrade our
applications that use XMLC 2.3.1
<br>
to the
<br>
newest XMLC version.
<br>
Our applications are deployed both
under the Tomcat 6.0.29
<br>
application server and Enhydra
application server (based on
<br>
Tomcat
<br>
6.0.29).
<br>
<br>
There are two issues I faced:
<br>
<br>
1) when deploying under the Tomcat,
XMLC JAR files are placed
<br>
together with the application JAR
files into application's
<br>
WEB-INF\lib folder (so application
classloader is used to load
<br>
them).
<br>
In this case, XMLC can't load
resources (*.html and *.xmlc
<br>
files)
<br>
from JAR file. When resources are
not in the JAR file but
<br>
unpacked
<br>
into WEB-INF\classes folder
everything works.
<br>
<br>
After "patching" the method
getPathURLFromClasspath() from
<br>
XMLCDeferredParsingFactory to add:
<br>
<br>
if (srcURL !=
null&&
<br>
srcURL.toString().indexOf(".jar")>=
0) {
<br>
try {
<br>
String mdurl =
srcURL.toString();
<br>
srcURL = new
URL("jar:"
<br>
+ mdurl.substring(0,
<br>
mdurl.indexOf(".jar")) + ".jar!/"
<br>
+
<br>
mdurl.substring(mdurl.indexOf(".jar")
+ 4));
<br>
} catch
(Exception ex) {
<br>
}
<br>
}
<br>
<br>
after the line:
<br>
<br>
URL srcURL =
<br>
fDynamicClassLoader.getResource(path);
<br>
<br>
it works fine.
<br>
<br>
2) when deploying under Enhydra
application server or under
<br>
Tomcat,
<br>
but instead of putting XMLC JAR
files into application's
<br>
WEB-INF\lib,
<br>
we put it into Tomcat's lib folder,
XMLC can't find
<br>
resources no
<br>
matter if resources are inside JAR
file or unpacked, and it
<br>
can't
<br>
find it even in the case I put
application's JAR file into
<br>
Tomcat's
<br>
lib folder.
<br>
<br>
Is it a bug in XMLC? Can somebody
help?
<br>
<br>
Regards,
<br>
Sasa.
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
--------------020901060605040802070005--
------------=_1301394059-30467-16120
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
------------=_1301394059-30467-16120--