[ 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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.