You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "J.Pietschmann" <j3...@yahoo.de> on 2002/05/31 23:30:16 UTC
Saxon complaining about xmlns attributes
Hi,
I get the following from my installation of Cocoon 2.0.2 on
Websphere 3.5.4:
ERROR (2002-05-30) 17:17.44:821 [core.xslt-processor] (...)
Worker#5/TraxErrorHandler: Error in TraxTransformer:
... SystemID: file:/.../spec.xsl; Line#: 5; Column#: -1
javax.xml.transform.TransformerConfigurationException:
Attribute xmlns:xsl is not allowed on this element
I have Saxon 6.5.4 followed by xerces-1.4.4.jar in the classpath
(all before the WebSphere cruft). The parser configuration in
cocoon.xconf is:
<xml-parser class="org.apache.avalon.excalibur.xml.XercesParser"
logger="core.xml-parser">
<parameter name="validate" value="false"/>
<parameter name="namespace-prefixes" value="false"/>
<parameter name="stop-on-warning" value="true"/>
<parameter name="stop-on-recoverable-error" value="true"/>
<parameter name="reuse-parsers" value="false"/>
Additionally the servlet parameter org.apache.avalon.excalibur.xml.Parser
is set to org.apache.avalon.excalibur.xml.XercesParser
Namespace-prefixes *is* set to false, as recommended. I read the
comment that this setting suppresses passing the xmlns as
attributes to the XML consumer (i.e. Saxon).
Is there a way to get rid of this log-hogging annoyances? Should
I use Xerces 2.0.0? The 1.4.4 jar is a legacy from an earlier
Cocoon 2.0.0 installation, I can change it.
J.Pietschmann
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Saxon complaining about xmlns attributes
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Sylvain Wallez wrote:
> The parameters listed above are for JaxpParser. XercesParser doesn't
> handle them and forces namespace-prefixes to true.
> So please switch to JaxpParser which cleanly handles this. Note that
> this may require to upgrade to a newer version of Xerces (don't now JAXP
> support in 1.4.4)
Thanks for the info. The problem is that I use Websphere 3.5 and the
recipe demands using XercesParser...
BTW Xerces supports JAXP from at least 1.2.1
It would be nice to have a short notice about the restriction
in cocoon.xconf.
J.Pietschmann
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Saxon complaining about xmlns attributes
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
J.Pietschmann wrote:
> Hi,
> I get the following from my installation of Cocoon 2.0.2 on
> Websphere 3.5.4:
>
> ERROR (2002-05-30) 17:17.44:821 [core.xslt-processor] (...)
> Worker#5/TraxErrorHandler: Error in TraxTransformer:
> ... SystemID: file:/.../spec.xsl; Line#: 5; Column#: -1
> javax.xml.transform.TransformerConfigurationException:
> Attribute xmlns:xsl is not allowed on this element
>
> I have Saxon 6.5.4 followed by xerces-1.4.4.jar in the classpath
> (all before the WebSphere cruft). The parser configuration in
> cocoon.xconf is:
>
> <xml-parser class="org.apache.avalon.excalibur.xml.XercesParser"
> logger="core.xml-parser">
> <parameter name="validate" value="false"/>
> <parameter name="namespace-prefixes" value="false"/>
> <parameter name="stop-on-warning" value="true"/>
> <parameter name="stop-on-recoverable-error" value="true"/>
> <parameter name="reuse-parsers" value="false"/>
>
> Additionally the servlet parameter org.apache.avalon.excalibur.xml.Parser
> is set to org.apache.avalon.excalibur.xml.XercesParser
>
> Namespace-prefixes *is* set to false, as recommended. I read the
> comment that this setting suppresses passing the xmlns as
> attributes to the XML consumer (i.e. Saxon).
>
> Is there a way to get rid of this log-hogging annoyances? Should
> I use Xerces 2.0.0? The 1.4.4 jar is a legacy from an earlier
> Cocoon 2.0.0 installation, I can change it.
The parameters listed above are for JaxpParser. XercesParser doesn't
handle them and forces namespace-prefixes to true.
So please switch to JaxpParser which cleanly handles this. Note that
this may require to upgrade to a newer version of Xerces (don't now JAXP
support in 1.4.4)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
map:aggregate fails to continue if any parts fail...
Posted by Per Kreipke <pe...@onclave.com>.
If any map:part fails to load, it seems as if the rest of the map:part's
aren't tried.
However, the parts that have succeeded up to that point are returned.
Is there a way to control that behavior? If not:
- is there a way to achieve what map:aggregate does a different way? Is
CInclude the equivalent? Or perhaps map:select?
- It seems to me that perhaps the proper behavior is for either the entire
pipeline to fail (or be caught by handle-errors) or for the pipeline to
continue processing, leaving out only the broken map:part.
Per
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
map:aggregate fails to continue if any parts fail...
Posted by Per Kreipke <pe...@onclave.com>.
If any map:part fails to load, it seems as if the rest of the map:part's
aren't tried.
However, the parts that have succeeded up to that point are returned.
Is there a way to control that behavior? If not:
- is there a way to achieve what map:aggregate does a different way? Is
CInclude the equivalent? Or perhaps map:select?
- It seems to me that perhaps the proper behavior is for either the entire
pipeline to fail (or be caught by handle-errors) or for the pipeline to
continue processing, leaving out only the broken map:part.
Per
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>