[ mx4j-Bugs-834296 ] common.xsl "str" template error
"SourceForge.net" <[email protected]>
| Newsgroups | gmane.comp.java.mx4j.devel |
|---|---|
| Message-ID | <[email protected]> |
Bugs item #834296, was opened at 2003-11-01 16:09
Message generated for change (Comment added) made by btscully
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=834296&group_id=47745
Category: HTTP Adaptor
Group: Release 1.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brian Scully (btscully)
Assigned to: Brian Scully (btscully)
Summary: common.xsl "str" template error
Initial Comment:
Per discussion on mx4j-devel with Carlos, excerpted
from the mx4j-user list:
Niklas Berg wrote:
Would it help you if I told that is seems to be caused
by the row saying:
'<xsl:when test="contains($text, $paramText)">'
in the template 'replace-param' defined in the
file 'common.xsl'
A call to 'str' (which calls replace-param) looking like
this:
<xsl:call-template name="str">
<xsl:with-param
name="id">mbean.mbean.description</xsl:with-param>
<xsl:with-param name="p0"><xsl:value-of
select="@description"/></xsl:with-param>
</xsl:call-template>
causes the message below (where 'description'
obviously comes from
"@description" above):
SystemId Unknown; Line #14; Column #-1; Cannot add
attribute description
after child nodes or before an element is produced.
Attribute will be
ignored.
Anything beyond this research is beyond my
capabilities :(
> I've seeing the samething for a while. It seems that
some changes in
> xalan may have generated that. I've tried to trace
the problem but I
> have not a good answer at this time.
>
> Any patch would be appreciated :-)
>
> Regards
> Carlos
>
> Niklas Bergh wrote:
> >There is a template in common.xsl named 'str' (row
388) that is used to
> >extract items from the strings_XX.xml files. For
parameters this template
> >takes in one ID, which identifies the string resource
requested, and
another
> >two parameters named p0 and p1. p0 and p1 can be
used to supply one or
two
> >strings which will be inlined into the language-
specific string wherever
> >that one contains either of the sequences '{0}'
or '{1}'. This
> >functionallity is, amongst other things, used to
generate the 'Domain:
> ><domainname>' strings which is supposed to be
displayed by the
> >serverbydomain page... Right now my
serverbydomain page displays only
> >'Domain: ' instead of that...
> >
> >I used the Oxygen XML editor to apply the
serverbydomain XSL to a
> >serverbydomain XML it worked just fine there......
> >
> >I am also seeing a strange message printed to
stderr now and then..
> >'SystemId Unknown; Line #12; Column #-1; Cannot
add attribute name after
> >child nodes or before an element is produced.
Attribute will be ignored.'
> >Could this be related in some way?
> >
----------------------------------------------------------------------
>Comment By: Brian Scully (btscully)
Date: 2003-11-09 13:39
Message:
Logged In: YES
user_id=234750
I have confirmed that this bug does not occur in xalan-j
2.5.2. JRE 1.3 is a drop-in replacement of the appropriate
XML packages - and these will be committed to CVS.
Unfortunately, until Sun upgrades the version of Xalan in their
distribution, this bug will persist on JRE 1.4. The reason for
this is that Sun packages the Xalan classes in the rt.jar.
These can be overridden by using the -Xbootclasspath/p:
switch, however - to do this would put one in violation of the
Binary License Agreement agreed to on download of the JRE.
The Xalan group's FAQ (http://xml.apache.org/xalan-
j/faq.html#faq-N100CB) also suggests putting xalan.jar, xml-
apis.jar, and xercesImpl.jar in the <java home>/lib/endorsed
directory. This also worked for me. Make sure that you
close all running VMs to make sure that your additions to this
directory become available. This last point is probably due to
Java's latest security bug - referred to as a cross-site
scripting hole on Bugtraq.
I am closing this bug and marking it Fixed - for JRE 1.3 users,
the Xalan upgrade should fix it directly. For JRE 1.4 users,
the recommended workaround is to use the endorsed
standards override mechanism.
----------------------------------------------------------------------
Comment By: Perry Dillard (perrydillard)
Date: 2003-11-05 12:37
Message:
Logged In: YES
user_id=881519
Oops, quick update to my last comment. I just did some
testing with the latest and greatest xalan-j 2.5.2 and the
problem seems to be fixed.
=Perry Dillard
Senior Member Technical Team
Epok, Inc.
http://www.epok.net
----------------------------------------------------------------------
Comment By: Perry Dillard (perrydillard)
Date: 2003-11-05 12:30
Message:
Logged In: YES
user_id=881519
I have used XMLSPY home edition to successfully render the
results from an invoke using the invoke.xsl and common.xsl so
I do not think there is a problem with the stylesheets
themselves, including the "str" template. It clearly works if
you put static text in there to use as a substitution when
using xalan. I think there is some error with xalan making the
attribute value available at the time the template is called
from within another template. I am currently trying to find a
solution. Temporarily I have moved some of the p0 params
outside the call to the template and just display them using
<xsl:value-of select="@return"/> or whatever. That seems to
work for the moment, at least on ones where there is only the
one substitution parameter.
=Perry Dillard
Senior Member Technical Team
Epok, Inc.
http://www.epok.net
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=450647&aid=834296&group_id=47745
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/