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