You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2003/03/03 21:42:22 UTC

DO NOT REPLY [Bug 17619] New: - ClassLoader Problems with XMLParser and XMLParser reuse

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17619>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17619

ClassLoader Problems with XMLParser and XMLParser reuse

           Summary: ClassLoader Problems with XMLParser and XMLParser reuse
           Product: Commons
           Version: 1.0 Alpha
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Jelly
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: vb@bigdot.de


Hello,

i had problems integrating jelly because of the ClassLoader set to the 
JellyContext is not promoted to the XMLParser. That leads to 
ClassNotFoundExceptions in resolving custom TagLibs. This should be added in 
JellyContext compileScript methods.

The use of XMLParser in JellyContext needs a little more documentation not 
only because of 
a new XMLParser is always instantiated in compileScript(String uri) and 
compileScript(URL url) uses the per thread instance. Is it ok that the 
ImportTag therefore indirectly uses the same thread instance parser?

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org