[xmlc] Re: Re: Re: Re: Re: Re: Re: Re: Re: Re: Issues with XMLC 2.3.2

This is a multi-part message in MIME format...

------------=_1301315738-30467-16047
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jake, first of all, thanks a lot for your effort!

...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.
Don't know if this can be somehow configured to specify the custom one? 
options.xmlc?

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;
    }

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.

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:

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?

Greetings,
Sasa.


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.
>>>>>>>>>>


------------=_1301315738-30467-16047
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

------------=_1301315738-30467-16047--