You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Davanum Srinivas <di...@yahoo.com> on 2000/12/07 16:58:06 UTC
[C2][Xalan2J] Extension Handler Error with Fix (waz Re: [C2]: Namespace bug in XalanTransformer)
Scott,
There was a change in org\apache\xalan\extensions\ExtensionHandler.java which is affecting
Cocoon2. Extension Handler now tries to use getContextClassLoader to load the class. This is
failing for the classes that we need for some reason. Here's a patch which helps. Basically if the
class is not found by getContextClassLoader then just use Class.forName() as it was earlier
(Java1).
Thanks,
dims
======================== Here's the modified function in ExtensionHandler.java ===============
/**
* Replacement for Class.forName. This method loads a class using the context class loader
* if we're running under Java2 or higher. If we're running under Java1, this
* method just uses Class.forName to load the class.
*/
static Class getClassForName(String className)
throws ClassNotFoundException
{
Class result = null;
if (getCCL != null)
{
try {
ClassLoader contextClassLoader =
(ClassLoader) getCCL.invoke(Thread.currentThread(), NO_OBJS);
result = contextClassLoader.loadClass(className);
}
catch (ClassNotFoundException cnfe)
{
try {
result = Class.forName(className);
} catch (Exception e){
}
if(result == null)
throw cnfe;
}
catch (Exception e)
{
getCCL = null;
result = Class.forName(className);
}
}
else
result = Class.forName(className);
return result;
}
========================================================================================
--- Scott Boag/CAM/Lotus <Sc...@lotus.com> wrote:
>
> This was a really dumb bug in Xalan that occured when copying an element.
> I just checked in a fix.
>
> BTW, please be sure to CC the Xalan-dev list if you suspect a Xalan bug.
>
> -scott
>
>
>
>
>
>
> "Carsten
>
> Ziegeler" To: <co...@xml.apache.org>
>
> <cziegeler@su cc: (bcc: Scott Boag/CAM/Lotus)
>
> ndn.de> Subject: [C2]: Namespace bug in XalanTransformer
>
>
>
> 12/06/2000
>
> 06:53 AM
>
> Please
>
> respond to
>
> cocoon-dev
>
>
>
>
>
>
>
>
>
> Hello,
>
> namespaces are not correctly handled by the current Xalan Version inside
> C2.
> The endElement event does not contain the correct information. Here is my
> simple test case.
>
> If you use the following XML file:
>
> <?xml version="1.0"?>
> <page xmlns:sunshine="http://sunshine.sundn.de/sunshine/1.0">
> <test>
> <sunshine:wrong/>
> </test>
> </page>
>
> and this pipeline:
>
> <map:generate src="test.xml"/>
> <map:transform src="test.xsl"/>
> <map:transform type="log">
>
> with a stylesheet which this stylesheet:
>
> <xsl:template match="test">
> <xsl:apply-templates/>
> </xsl:template>
>
> <xsl:template match="node()|@*"><xsl:copy>
> <xsl:apply-templates select="node()|@*"/>
> </xsl:copy></xsl:template>
>
> The log transformer gets the following events:
> [setup] ---------------------------- [Wed Dec 06 12:47:33 GMT+01:00 2000]
> ----------------------------
> [startDocument]
> [startElement] uri=null,local=page,raw=page
> [characters]
>
> [characters]
>
> [startPrefixMapping]
> prefix=sunshine,uri=http://sunshine.sundn.de/sunshine/1.0
> [startElement]
> uri=http://sunshine.sundn.de/sunshine/1.0,local=wrong,raw=sunshine:wrong
> [ ] 1.
>
uri=http://www.w3.org/2000/xmlns/,local=sunshine,qname=xmlns:sunshine,type=CDATA,value=http://sunshine.sundn.de/sunshine/1.0
>
> [endElement] uri=,local=,qname=sunshine:wrong
> [endPrefixMapping] prefix=sunshine
> [characters]
>
> [characters]
>
> [endElement] uri=,local=,qname=page
> [endDocument]
>
> The endElement event has no uri and no local name set.
>
> Regards
> Carsten Ziegeler
>
> Open Source Group sunShine - Lighting up e:Business
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto:cziegeler@sundn.de
> ================================================================
> (See attached file: test.xml)(See attached file: test.xsl)
>
>
> ATTACHMENT part 2 application/octet-stream name=test.xml
> ATTACHMENT part 3 application/octet-stream name=test.xsl
=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
Re: [C2][Xalan2J] Extension Handler Error with Fix (waz Re: [C2]:
Namespace bug in XalanTransformer)
Posted by Gary L Peskin <ga...@firstech.com>.
Davanum Srinivas wrote:
>
> Scott,
>
> There was a change in org\apache\xalan\extensions\ExtensionHandler.java which is affecting
> Cocoon2. Extension Handler now tries to use getContextClassLoader to load the class. This is
> failing for the classes that we need for some reason. Here's a patch which helps. Basically if the
> class is not found by getContextClassLoader then just use Class.forName() as it was earlier
> (Java1).
>
> Thanks,
> dims
>
Dims --
The reason for this is that we now look to the ContextClassLoader, if it
exists, to actually do the load. This requires that your extensions
move from the Xalan directory or .jar (or elsewhere in the CLASSPATH)
into the appropriate directory for that ContextClassLoader. I think in
Tomcat this is called a Context. Any extensions then, must be in the
appropriate Tomcat Context.
With your change, if the extension is not found in the Context, we fall
back to getting it from the Xalan .jar or system CLASSPATH. Is this
what you want or should we force users to move the extensions into the
appropriate Context(s). If this is truly what you want, I'll commit the
change forthwith.
Gary
Re: [C2][Xalan2J] Extension Handler Error with Fix (waz Re: [C2]:
Namespace bug in XalanTransformer)
Posted by Gary L Peskin <ga...@firstech.com>.
Davanum Srinivas wrote:
>
> Scott,
>
> There was a change in org\apache\xalan\extensions\ExtensionHandler.java which is affecting
> Cocoon2. Extension Handler now tries to use getContextClassLoader to load the class. This is
> failing for the classes that we need for some reason. Here's a patch which helps. Basically if the
> class is not found by getContextClassLoader then just use Class.forName() as it was earlier
> (Java1).
>
> Thanks,
> dims
>
Dims --
The reason for this is that we now look to the ContextClassLoader, if it
exists, to actually do the load. This requires that your extensions
move from the Xalan directory or .jar (or elsewhere in the CLASSPATH)
into the appropriate directory for that ContextClassLoader. I think in
Tomcat this is called a Context. Any extensions then, must be in the
appropriate Tomcat Context.
With your change, if the extension is not found in the Context, we fall
back to getting it from the Xalan .jar or system CLASSPATH. Is this
what you want or should we force users to move the extensions into the
appropriate Context(s). If this is truly what you want, I'll commit the
change forthwith.
Gary