from:"JIRA"

[
https://issues.apache.org/jira/browse/XALANC-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13644587#comment-13644587
]

Steven J. Hathaway commented on XALANC-743:
---

This issue should be for XERCESC instead of XALANC. We use Xerces for the XML
parser and transcoder library.

I don't know how you were able to put a UTF-16 high-surrogate value at the end
of a string without truncation unless it was a misuse of UTF-8.

- - -

FYI: Unicode Discussion - The valid code points related to UTF-8/UTF-16

Unicode values are restricted to a subset of 21-bit binary values.

Special value 0x is an invalid Unicode code-point. This value may be used
as a terminator for code-point sequences. This value should not be encoded as
UTF-8 or UTF-16.

Surrogate values for UTF-16 are not valid code-point values. They are used to
translate pairs of 16-bit quantities into code-point values.

Values larger than 0x10 are not valid code-point values. This is the limit
of the UTF-16 algorithm.

The UTF-8 algorithm can effectively encode 31-bits of binary value, but only
the range 0x01 to 0x10 are valid Unicode code-point values.

- - -
Sincerely,
Steven J. Hathaway

XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till
out of memory
---

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-743) XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till out of memory

2013-04-29 Thread Jiangbei Fan (JIRA)

[
https://issues.apache.org/jira/browse/XALANC-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13644611#comment-13644611
]

Jiangbei Fan commented on XALANC-743:
-

I was only calling XalanTransformer::transform with an input file and
stylesheet file. And it loops inside of the transcode as I pointed out. The
input file contains characters 360 237 230 201 (with od -c). It is one unicode
character, and two XalanDOMChars in the buffer. So when the first wide char is
the last wide char in the buffer of XalanOutputStream it loops forever.

XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till
out of memory
---

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-743) XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till out of memory

[
https://issues.apache.org/jira/browse/XALANC-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13644613#comment-13644613
]

Steven J. Hathaway commented on XALANC-743:
---

A similar bug XERCESC-1987 has been reported and fixed in the Xerces-C
subversion trunk. The fix will not be backported to Xerces-C version 2.8.

Steven J. Hathaway

XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till
out of memory
---

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Issue Comment Deleted] (XALANC-743) XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till out of memory

[
https://issues.apache.org/jira/browse/XALANC-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Steven J. Hathaway updated XALANC-743:
--

Comment: was deleted

(was: A similar bug XERCESC-1987 has been reported and fixed in the Xerces-C
subversion trunk. The fix will not be backported to Xerces-C version 2.8.

Steven J. Hathaway)

XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till
out of memory
---

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-743) XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till out of memory

[
https://issues.apache.org/jira/browse/XALANC-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13644627#comment-13644627
]

Steven J. Hathaway commented on XALANC-743:
---

You should check the encodings for your input file and stylesheet file. Do they
begin with a {byte-order-mark} for UTF-16, or are they assuming default UTF-8
encoding in absence of an ?xml ? document identifier.

A similar bug XERCESC-1987 has been reported and fixed in the Xerces-C
subversion trunk. This artifact is related to a chinese character. The fix
will not be backported to Xerces-C version 2.8.

Steven J. Hathaway

XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till
out of memory
---

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2572) Extension implementation for data grouping

2013-05-09 Thread Mukul Gandhi (JIRA)

Mukul Gandhi created XALANJ-2572:


 Summary: Extension implementation for data grouping
 Key: XALANJ-2572
 URL: https://issues.apache.org/jira/browse/XALANJ-2572
 Project: XalanJ2
  Issue Type: Task
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Xalan-extensions
Affects Versions: 2.7.1
Reporter: Mukul Gandhi
Assignee: Steven J. Hathaway
Priority: Minor


I thought the Xalan forum may be right place to post this.

I've been thinking on this topic lately. I wrote a Xalan extension quite 
equivalent to XSLT 2.0 for-each-group element. The implementation I'm 
submitting doesn't provide full range of capabilities as XSLT 2.0 
for-each-group element, but it seems to be fairly useful to me for XSLT 1.0 
environments. The well known grouping techniques for XSLT 1.0 environments like 
muenchian grouping have some limitations I think, for example its difficult to 
specify multilevel groups with muenchian technique.

I'm providing source code of the extension implementation, and few examples.

The example files should be collected as follows,

*l1.*

*l2.*

The downside of this extension is that, its an extension and not pure XSLT 1.0. 
But it may be used, if Xalan has to be the XSL environment.

There might be few bugs with the submission I'm providing, since I've done 
limited testing on this. Any feedback is welcome.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2572) Extension implementation for data grouping

2013-05-09 Thread Mukul Gandhi (JIRA)

[
https://issues.apache.org/jira/browse/XALANJ-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mukul Gandhi updated XALANJ-2572:
-

Attachment: test_l2.xsl
test_l1.xsl
output_l2.xml
test_l2.xml
output_l1.xml
test_l1.xml

I'm attaching the example files.

Extension implementation for data grouping
--

Key: XALANJ-2572
URL: https://issues.apache.org/jira/browse/XALANJ-2572
Project: XalanJ2
Issue Type: Task
Security Level: No security risk; visible to anyone(Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: Xalan-extensions
Affects Versions: 2.7.1
Reporter: Mukul Gandhi
Assignee: Steven J. Hathaway
Priority: Minor
Attachments: GroupExtensionUtil.java, Group.java, output_l1.xml,
output_l2.xml, test_l1.xml, test_l1.xsl, test_l2.xml, test_l2.xsl

I thought the Xalan forum may be right place to post this.
I've been thinking on this topic lately. I wrote a Xalan extension quite
equivalent to XSLT 2.0 for-each-group element. The implementation I'm
submitting doesn't provide full range of capabilities as XSLT 2.0
for-each-group element, but it seems to be fairly useful to me for XSLT 1.0
environments. The well known grouping techniques for XSLT 1.0 environments
like muenchian grouping have some limitations I think, for example its
difficult to specify multilevel groups with muenchian technique.
I'm providing source code of the extension implementation, and few examples.
The example files should be collected as follows,
*l1.*
*l2.*
The downside of this extension is that, its an extension and not pure XSLT
1.0. But it may be used, if Xalan has to be the XSL environment.
There might be few bugs with the submission I'm providing, since I've done
limited testing on this. Any feedback is welcome.

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2572) Extension implementation for data grouping

2013-05-09 Thread Mukul Gandhi (JIRA)

[
https://issues.apache.org/jira/browse/XALANJ-2572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13653455#comment-13653455
]

Mukul Gandhi commented on XALANJ-2572:
--

Wanted to mention this,

This extension implementation emits grouping results wrapped within
groups/group/@key fragments. This is very much hard coded within this
extension. I couldn't avoid such a design, since Xalan extension framework
looks like cannot provide a single pass XSLT 2.0 for-each-group like semantics
(with things like current-group(), current-grouping-key() available as a
result).

This may be overcome by post processing within the stylesheet, using built-in
node-set extension for a user specific rendering of grouping results.

Extension implementation for data grouping
--

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-744) XalanLocator::getSystemId() can return NULL, cause crash

2013-05-14 Thread Michael Chisholm (JIRA)

Michael Chisholm created XALANC-744:
---

 Summary: XalanLocator::getSystemId() can return NULL, cause crash
 Key: XALANC-744
 URL: https://issues.apache.org/jira/browse/XALANC-744
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Windows, Visual Studio 2010
Reporter: Michael Chisholm
Assignee: Steven J. Hathaway
Priority: Critical


I think this is a copy-paste bug, introduced in r1388736:

Index: XalanLocator.hpp
===
--- XalanLocator.hpp(revision 1388735)
+++ XalanLocator.hpp(revision 1388736)
@@ -67,17 +67,19 @@
 static const XalanDOMChar*
 getPublicId(
 const Locator*  theLocator,
-const XalanDOMChar* theAlternateId = 0)
+const XalanDOMChar* theAlternateId = s_dczero)
 {
-return theLocator == 0 ? theAlternateId : theLocator-getPublicId();
+return theLocator == 0 ? theAlternateId : (theLocator-getPublicId() ?
+theLocator-getPublicId() : theAlternateId);
 }

 static const XalanDOMChar*
 getSystemId(
 const Locator*  theLocator,
-const XalanDOMChar* theAlternateId = 0)
+const XalanDOMChar* theAlternateId = s_dczero)
 {
-return theLocator == 0 ? theAlternateId : theLocator-getSystemId();
+return theLocator == 0 ? theAlternateId : (theLocator-getSystemId() ?
+theLocator-getPublicId() : theAlternateId);
 }

 static XalanFileLoc
@@ -122,6 +124,8 @@

 XalanLocator
 operator=(const XalanLocator);
+
+const static XalanDOMChar s_dczero = 0;
 };

Notice that in the getSystemId() method, theLocator-getPublicId() is called.  
I think that was meant to be theLocator-getSystemId().  This caused a crash 
when I used Xalan.exe because it sets up its XSLTInputSources with system Ids, 
but not public Ids.  Then, during transformation, XalanLocator::getSystemId() 
is called, which returns the NULL public Id, which is passed to the 
XalamDomString constructor, which causes the crash.

I just switched the call to theLocator-getSystemId() and the crash disappeared.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-1544) AttributesImplSerializer slow for low number of attributes

2013-05-24 Thread David Boden (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANJ-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13666340#comment-13666340
 ] 

David Boden commented on XALANJ-1544:
-

Hi. I have a program which has 17 attributes per element for a large number of 
elements, so it just breaks through the limit of 12. I've raised an Oracle JDK 
request for enhancement (2512518) to make the number a bit more flexible. I 
find that the switch to HashMap significantly reduces the performance of my 
application.

Here's the text in the request for enhancement:

The com.sun.org.apache.xml.internal.serializer.AttributesImplSerializer 
contains an optimisation for XML elements with a large number of attributes.

It extends the AttributesImpl class and changes behaviour when over 12 
attributes are to be stored in an element. The 12 is hardcoded in the class 
with a comment of:

This is the number of attributes before switching to the hash table, and can be 
tuned, but 12 seems good for now - Brian M.

I have a use-case with 300,000 conversions with exactly 17 attributes each. The 
memory and garbage collection performance of my application is severely reduced 
when going from less than 12 to more than 12 attributes. The optimisation 
creates large numbers of new strings and hashmap entries within the 
switchOverToHash() method. This shows up in JVisualVM as the largest task 
that's taking place.

The SerializerBase class contains:
protected AttributesImplSerializer m_attributes = new 
AttributesImplSerializer();

This provides no opportunity to use the simpler AttributesImpl instead. There's 
also no way to change the hardcoded number 12.

 AttributesImplSerializer slow for low number of attributes
 --

 Key: XALANJ-1544
 URL: https://issues.apache.org/jira/browse/XALANJ-1544
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
  Components: Serialization
Affects Versions: 2.7.1
 Environment: Operating System: Other
 Platform: Other
Reporter: Brian Minchau
 Attachments: 
 ASF.LICENSE.NOT.GRANTED--AttributesImplSerializer.patch.txt


 org.xml.sax.helpers.AttributesImpl is faster for a low number of attributes, 
 but it has a linear search for getIndex(String qname) makes it Order N*N as N 
 attributes are added, so some things ran VERY slowly.  
 AttributesImplSerializer has a Hashtable to speed this up for large N, but it 
 is about twice as slow for small N.  Suggest a hybrid solution that only uses 
 the Hashtable after 10 or so attributes have been added.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-738) Issue building DoubleSupport.hpp on Solaris with use if isnan

2013-05-31 Thread Ivan Pechorin (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANC-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671713#comment-13671713
 ] 

Ivan Pechorin commented on XALANC-738:
--

The same problem also applies to the latest version of SunCC (Solaris Studio 
12.3):

/builddir/xml-xalan/src/xalanc/PlatformSupport/DoubleSupport.hpp, line 86: 
Error: isnan is not a member of std.
1 Error(s) detected.

And the same fix works for SunCC too.
Thank you.

 Issue building DoubleSupport.hpp on Solaris with use if isnan
 -

 Key: XALANC-738
 URL: https://issues.apache.org/jira/browse/XALANC-738
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Solaris 10u10
 gcc 3.2.3
 xerces-c 3.1.1
Reporter: Robert Hillier
Assignee: Steven J. Hathaway
  Labels: build

 When building on Solaris, the compilation of DoubleSupport.hpp fails with 
 message:
 isnan is not in namespace std
 I have been able to work around this my making the following change:
 #if defined(SOLARIS)
 #include math.h
 #endif
 static bool
 isNaN(doubletheNumber)
 {
 #if defined(_MSC_VER)
 return _isnan(theNumber) != 0;
 #elif defined(XALAN_POSIX2_AVAILABLE)  !defined(CYGWIN)  !defined(MINGW)
 #if defined(XALAN_NO_STD_NAMESPACE)
 return isnam(theNumber) != 0;
 #else
 #if defined(SOLARIS)
 return isnan(theNumber) != 0;
 #else
 return std::isnan(theNumber) != 0;
 #endif
 #endif
 #else
 return s_NaN == theNumber;
 #endif
 }
 This fixes this particular problem, but I wanted to be sure I'm not missing 
 something else.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Comment Edited] (XALANC-738) Issue building DoubleSupport.hpp on Solaris with use if isnan

2013-05-31 Thread Ivan Pechorin (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANC-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671713#comment-13671713
 ] 

Ivan Pechorin edited comment on XALANC-738 at 5/31/13 6:23 PM:
---

The same problem also applies to the latest version of SunCC (Solaris Studio 
12.3) on Solaris 11:

/builddir/xml-xalan/src/xalanc/PlatformSupport/DoubleSupport.hpp, line 86: 
Error: isnan is not a member of std.
1 Error(s) detected.

And the same fix works for SunCC too.
Thank you.

  was (Author: ipechorin):
The same problem also applies to the latest version of SunCC (Solaris 
Studio 12.3):

/builddir/xml-xalan/src/xalanc/PlatformSupport/DoubleSupport.hpp, line 86: 
Error: isnan is not a member of std.
1 Error(s) detected.

And the same fix works for SunCC too.
Thank you.
  
 Issue building DoubleSupport.hpp on Solaris with use if isnan
 -

 Key: XALANC-738
 URL: https://issues.apache.org/jira/browse/XALANC-738
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Solaris 10u10
 gcc 3.2.3
 xerces-c 3.1.1
Reporter: Robert Hillier
Assignee: Steven J. Hathaway
  Labels: build

 When building on Solaris, the compilation of DoubleSupport.hpp fails with 
 message:
 isnan is not in namespace std
 I have been able to work around this my making the following change:
 #if defined(SOLARIS)
 #include math.h
 #endif
 static bool
 isNaN(doubletheNumber)
 {
 #if defined(_MSC_VER)
 return _isnan(theNumber) != 0;
 #elif defined(XALAN_POSIX2_AVAILABLE)  !defined(CYGWIN)  !defined(MINGW)
 #if defined(XALAN_NO_STD_NAMESPACE)
 return isnam(theNumber) != 0;
 #else
 #if defined(SOLARIS)
 return isnan(theNumber) != 0;
 #else
 return std::isnan(theNumber) != 0;
 #endif
 #endif
 #else
 return s_NaN == theNumber;
 #endif
 }
 This fixes this particular problem, but I wanted to be sure I'm not missing 
 something else.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2382) Namespace declarations are lost on transformation to DOMResult

2013-06-17 Thread Andy Scott (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANJ-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13686392#comment-13686392
 ] 

Andy Scott commented on XALANJ-2382:


Any movement on this? None of the workarounds work for me... It's crippling my 
progress :(

 Namespace declarations are lost on transformation to DOMResult
 --

 Key: XALANJ-2382
 URL: https://issues.apache.org/jira/browse/XALANJ-2382
 Project: XalanJ2
  Issue Type: Bug
  Components: DOM, JAXP, Xalan
Affects Versions: 2.7.1, 2.7
 Environment: Intel Pentium 4
 Windows 2000 SP4
 Sun JDK 6 (build 1.6.0-b105)
Reporter: Christian Koppen
 Attachments: output.txt, TransformerTest.java, 
 xalan-j2-XALANJ-2382.patch


 Have a look at the following snippet:
 a:a1 xmlns:a=http://a;
   xmlns:b=http://b;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  a:a2 xsi:type=b:B/
 /a:a1
 As you can see, the value of the attribute 'xsi:type' contains a namespace 
 prefix, which is declared in the root element.
 When I read this document as a StreamSource or SAXSource and transform it 
 with Xalan into a DOMResult, the namespaces are invalid because the namespace 
 declaration 'xmlns:b=http://b;' is lost:
 a:a1 xmlns:a=http://a;
   a:a2 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:type=b:B/
 /a:a1
 When I try to read the document as a DOMSource and try to transform it into a 
 DOMResult, an exception occurs ('NAMESPACE_ERR: An attempt is made to create 
 or change an object in a way which is incorrect with regard to namespaces.').
 I attach the example code and output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-746) Allow builds for GNU/kFreeBSD

Bill Blough created XALANC-746:
--

 Summary: Allow builds for GNU/kFreeBSD
 Key: XALANC-746
 URL: https://issues.apache.org/jira/browse/XALANC-746
 Project: XalanC
  Issue Type: Improvement
  Components: XalanC
Affects Versions: 1.11
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Minor


Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347196

Allow builds for systems running GNU/kFreeBSD. 

Patch against 1.11 attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANC-746) Allow builds for GNU/kFreeBSD


 [ 
https://issues.apache.org/jira/browse/XALANC-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Blough updated XALANC-746:
---

Attachment: kfreebsd-support.diff

Patch against Xalan 1.11

 Allow builds for GNU/kFreeBSD
 -

 Key: XALANC-746
 URL: https://issues.apache.org/jira/browse/XALANC-746
 Project: XalanC
  Issue Type: Improvement
  Components: XalanC
Affects Versions: 1.11
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Minor
 Attachments: kfreebsd-support.diff


 Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347196
 Allow builds for systems running GNU/kFreeBSD. 
 Patch against 1.11 attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-747) FTBFS when using ld flag --as-needed

Bill Blough created XALANC-747:
--

 Summary: FTBFS when using ld flag --as-needed
 Key: XALANC-747
 URL: https://issues.apache.org/jira/browse/XALANC-747
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11, 1.10
Reporter: Bill Blough
Assignee: Steven J. Hathaway
 Fix For: 1.11


Reference: http://bugs.debian.org/641289

Failure to build from source when linking with --as-needed flag.

Patch against 1.11 attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANC-747) FTBFS when using ld flag --as-needed


 [ 
https://issues.apache.org/jira/browse/XALANC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Blough updated XALANC-747:
---

Attachment: fix-ftbfs-ld-as-needed.diff

 FTBFS when using ld flag --as-needed
 

 Key: XALANC-747
 URL: https://issues.apache.org/jira/browse/XALANC-747
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.10, 1.11
Reporter: Bill Blough
Assignee: Steven J. Hathaway
 Fix For: 1.11

 Attachments: fix-ftbfs-ld-as-needed.diff


 Reference: http://bugs.debian.org/641289
 Failure to build from source when linking with --as-needed flag.
 Patch against 1.11 attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANC-748) Minor errors in README


 [ 
https://issues.apache.org/jira/browse/XALANC-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Blough updated XALANC-748:
---

Attachment: fix-readme-typos.diff

 Minor errors in README
 --

 Key: XALANC-748
 URL: https://issues.apache.org/jira/browse/XALANC-748
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Trivial
 Fix For: 1.11

 Attachments: fix-readme-typos.diff


 Minor typos in README.  
 Patch vs 1.11 attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-748) Minor errors in README

Bill Blough created XALANC-748:
--

 Summary: Minor errors in README
 Key: XALANC-748
 URL: https://issues.apache.org/jira/browse/XALANC-748
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Trivial
 Fix For: 1.11
 Attachments: fix-readme-typos.diff


Minor typos in README.  

Patch vs 1.11 attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Issue Comment Deleted] (XALANJ-2382) Namespace declarations are lost on transformation to DOMResult

2013-06-18 Thread Andy Scott (JIRA)


 [ 
https://issues.apache.org/jira/browse/XALANJ-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Scott updated XALANJ-2382:
---

Comment: was deleted

(was: Any movement on this? None of the workarounds seem to work for me... :()

 Namespace declarations are lost on transformation to DOMResult
 --

 Key: XALANJ-2382
 URL: https://issues.apache.org/jira/browse/XALANJ-2382
 Project: XalanJ2
  Issue Type: Bug
  Components: DOM, JAXP, Xalan
Affects Versions: 2.7.1, 2.7
 Environment: Intel Pentium 4
 Windows 2000 SP4
 Sun JDK 6 (build 1.6.0-b105)
Reporter: Christian Koppen
 Attachments: output.txt, TransformerTest.java, 
 xalan-j2-XALANJ-2382.patch


 Have a look at the following snippet:
 a:a1 xmlns:a=http://a;
   xmlns:b=http://b;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  a:a2 xsi:type=b:B/
 /a:a1
 As you can see, the value of the attribute 'xsi:type' contains a namespace 
 prefix, which is declared in the root element.
 When I read this document as a StreamSource or SAXSource and transform it 
 with Xalan into a DOMResult, the namespaces are invalid because the namespace 
 declaration 'xmlns:b=http://b;' is lost:
 a:a1 xmlns:a=http://a;
   a:a2 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:type=b:B/
 /a:a1
 When I try to read the document as a DOMSource and try to transform it into a 
 DOMResult, an exception occurs ('NAMESPACE_ERR: An attempt is made to create 
 or change an object in a way which is incorrect with regard to namespaces.').
 I attach the example code and output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2540) Very inefficient default behaviour for looking up DTMManager

2013-07-04 Thread Fleur Kelpin (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANJ-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13700323#comment-13700323
 ] 

Fleur Kelpin commented on XALANJ-2540:
--

It's worse. The lookup opens a ZipFile and this synchronizes my threads across 
different one-per-thread precompiled xpathexpression evals.

 Very inefficient default behaviour for looking up DTMManager
 

 Key: XALANJ-2540
 URL: https://issues.apache.org/jira/browse/XALANJ-2540
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
  Components: DTM, XPath
Affects Versions: 2.7.1, 2.7
Reporter: Lukas Eder

 I have analysed an issue that has been bothering me for some time. When 
 executing XPath evaluations, it looks like a very significant amount of time 
 is spent in the initialisation of the XPathContext. I have asked this 
 question on Stack Overflow and answered it myself:
 http://stackoverflow.com/questions/6340802/java-xpath-apache-jaxp-implementation-performance
 I think the default behaviour of 
 org.apache.xml.dtm.ObjectFactory.lookUpFactoryClassName() is quite 
 sub-optimal and should be improved, statically. I imagine, it is unlikely 
 that this configuration is going to change once classes have been loaded. 
 Hence, the fallback lookup of META-INF/service/org.apache.xml.dtm.DTMManager 
 should only be done once.
 For reference, here's the question and answer again in JIRA:
 
 I have come to an astonishing conclusion that this:
 Element e = (Element) 
 document.getElementsByTagName(SomeElementName).item(0);
 String result = ((Element) e).getTextContent();
 Seems to be an incredible 100x faster than this:
 // Accounts for 30%, can be cached
 XPathFactory factory = XPathFactory.newInstance();
 // Negligible
 XPath xpath = factory.newXPath();
 // Accounts for 70% (caching a compiled expression doesn't change much...)
 String result = (String) xpath.evaluate(
   //SomeElementName, document, XPathConstants.STRING);
 I'm using the JVM's default implementation of JAXP:
 org.apache.xpath.jaxp.XPathFactoryImpl
 org.apache.xpath.jaxp.XPathImpl
 I'm really confused, because it's easy to see how JAXP could optimise the 
 above XPath query to actually execute a simple getElementsByTagName() 
 instead. But it doesn't seem to do that. This problem is limited to around 
 5-6 frequently used XPath calls, that are abstracted and hidden by an API. 
 Those queries involve simple paths (e.g. /a/b/c, no variables, conditions) 
 against an always available DOM Document only. So, if an optimisation can be 
 done, it will be quite easy to achieve.
 
 I have debugged and profiled my test-case and Xalan/JAXP in general. I 
 managed to identify the big major problem in
 org.apache.xml.dtm.ObjectFactory.lookUpFactoryClassName()
 It can be seen that every one of the 10k test XPath evaluations led to the 
 classloader trying to lookup the DTMManager instance in some sort of default 
 configuration. This configuration is not loaded into memory but accessed 
 every time. Furthermore, this access seems to be protected by a lock on the 
 ObjectFactory.class itself. When the access fails (by default), then the 
 configuration is loaded from the xalan.jar file's
 META-INF/service/org.apache.xml.dtm.DTMManager
 configuration file. Every time!:
 Fortunately, this behaviour can be overridden by specifying a JVM parameter 
 like this:
 -Dorg.apache.xml.dtm.DTMManager=
   org.apache.xml.dtm.ref.DTMManagerDefault
 or
 -Dcom.sun.org.apache.xml.internal.dtm.DTMManager=
   com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault
 So here's a performance improvement overview for 10k consecutive XPath 
 evaluations of //SomeNodeName against a 90k XML file (measured with 
 System.nanoTime():
 measured library: Xalan 2.7.0 | Xalan 2.7.1 | Saxon-HE 9.3 | jaxen 
 1.1.3   
 
 without optimisation: 10400ms |  4717ms |  | 
 25500ms
 reusing XPathFactory:  5995ms |  2829ms |  |
 reusing XPath   :  5900ms |  2890ms |  |
 reusing XPathExpression :  5800ms |  2915ms |  16000ms | 
 25000ms
 adding the JVM param:  1163ms |   761ms |n/a   |

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e

[jira] [Created] (XALANC-749) Xalan ICU format-number problem

2013-07-09 Thread Erwin Brandenberger (JIRA)

Erwin Brandenberger created XALANC-749:
--

 Summary: Xalan ICU format-number problem
 Key: XALANC-749
 URL: https://issues.apache.org/jira/browse/XALANC-749
 Project: XalanC
  Issue Type: Bug
Affects Versions: 1.11
 Environment: Windows 8, ICU 5.1.2, Xerces-C 3.1.1 ICU compiled
Reporter: Erwin Brandenberger
Assignee: Steven J. Hathaway


I compiled the xalan libraries for ICU.

Now I want to use the format-number method, but when i use the decimal-format i 
got an unknown entity error (see below).

I checked with samples from the net, but they look the same I programmed.

Do have an idea what the problem is ?

Regards
Erwin

C:\Users\Erwin\Downloads\xalan_c-1.11-src\xalan-c-1.11\c\Build\Win32\VC10\Debug.ICUXalanTransform.exe
 Erwin.xml Erwin.xslt Erwin.html
XSLT warning: The call to 'format-number()' failed. (Occurred in an unknown 
entity, at line 8, column 8.)
Source tree node: #document.

Erwin.xslt

?xml version=1.0 encoding=ISO-8859-1?
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:decimal-format name=erwin grouping-separator=' decimal-separator=./
xsl:template match=/
html
body
xsl:value-of select=format-number(32345.564, '###,##0.00')/
xsl:value-of select=format-number(32345.564, '###,##0.00', 'erwin')/
/body
/html
/xsl:template
/xsl:stylesheet

Erwin.xml

?xml version=1.0 encoding=ISO-8859-1?
Erwin
/Erwin



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-750) Xalan ICU format-number problem

2013-07-09 Thread Erwin Brandenberger (JIRA)

Erwin Brandenberger created XALANC-750:
--

 Summary: Xalan ICU format-number problem
 Key: XALANC-750
 URL: https://issues.apache.org/jira/browse/XALANC-750
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Windows 8, ICU Library 51.2, Xerces-C 3.1.1 ICU compiled
Reporter: Erwin Brandenberger
Assignee: Steven J. Hathaway
 Fix For: 1.11


I compiled the xalan libraries for ICU.

Now I want to use the format-number method, but when i use the decimal-format i 
got an unknown entity error (see below).

I checked with samples from the net, but they look the same I programmed.

Do have an idea what the problem is ?

C:\Users\Erwin\Downloads\xalan_c-1.11-src\xalan-c-1.11\c\Build\Win32\VC10\Debug.ICUXalanTransform.exe
 Erwin.xml Erwin.xslt Erwin.html
XSLT warning: The call to 'format-number()' failed. (Occurred in an unknown 
entity, at line 8, column 8.)
Source tree node: #document.

Erwin.xslt

?xml version=1.0 encoding=ISO-8859-1?
xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:decimal-format name=erwin grouping-separator=' decimal-separator=./
xsl:template match=/
html
body
xsl:value-of select=format-number(32345.564, '###,##0.00')/
xsl:value-of select=format-number(32345.564, '###,##0.00', 'erwin')/
/body
/html
/xsl:template
/xsl:stylesheet

Erwin.xml

?xml version=1.0 encoding=ISO-8859-1?
Erwin
/Erwin


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2398) parsing big XMLs take very long time. A JAXRPC webservice request of soap size 2MB takes above 5 mins to complete parsing and start processing web service.

2013-07-11 Thread Saponenko Denis (JIRA)

[
https://issues.apache.org/jira/browse/XALANJ-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13705781#comment-13705781
]

Saponenko Denis commented on XALANJ-2398:
-

This is bug resolved in jdk
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6652519 but I want to use
xalan because Transformer.setParameter support Node objects. I tried to move
changes with StringBuffer to SAX2DOM realization but whis not resolve problem.

parsing big XMLs take very long time. A JAXRPC webservice request of soap
size 2MB takes above 5 mins to complete parsing and start processing web
service.
---

Key: XALANJ-2398
URL: https://issues.apache.org/jira/browse/XALANJ-2398
Project: XalanJ2
Issue Type: Bug
Components: transformation
Environment: Operating System: All
Platform: All
Reporter: SHEREEF ABDULLA
Attachments: JaxRPCProcessRequest.java, WrkingBigSOAP.txt

parsing bix XMLs take very long time. A JAXRPC webservice request of soap
size 2MB takes above 5 mins to complete parsing and start processing web
service.
Observed that the SOAP messages are read line by line and
CharacterDataImpl.append() is getting called for each line. This appends each
line to the string data which stores the previously read xml part. This call
results in many string additions (say 2+ for 1MB SOAP) of big string and
the thread is most of the time blocked in StringBuilder.expandcapacity due to
long string additions.
JAX RPC webservice with SOAP messages bigger than 1MB take 5 mins and more
just for the web service implementation to start working as the jaxrpc does a
SOAPMessage.getenvelop call to do HandlerChainImpl.checkMustUnderstand()
checking for the request message header. Same problem happens for response
also. for time being we commented checkMustUnderstand method so that the
parsing doesn't happen at all.
String additions for each of the lines would have been avoided, either by
creating the whole data single time or using string buffer instead of string.
I tried to modify the data field to use StringBuffer instead of String but
the underlying CoreDocumentImpl.modifiedCharacterData() and all underlying
calls takes the string params so couldn't go ahead with it.
bug # XERCESJ-102 looks like the same issue..

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-751) Segmentation fault in TestXSLT

2013-08-02 Thread Bill Blough (JIRA)

Bill Blough created XALANC-751:
--

 Summary: Segmentation fault in TestXSLT
 Key: XALANC-751
 URL: https://issues.apache.org/jira/browse/XALANC-751
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Debian GNU/Linux
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Critical



Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718303

TestXSLT segfaults under certain input instead of returning an error.  My 
testing indicates that this issue began in SVN rev 1388736, as 1388735 appears 
to exhibit the correct behavior.

The issue can be reproduced as follows:

$ cat var-in-xslkey.xsl
?xml version=1.0?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:param name=var/
xsl:key name=key match=*[@id != $var] use=''/
/xsl:stylesheet

$ xalan -xsl var-in-xslkey.xsl -in var-in-xslkey.xsl

Expected Results (1388735 and before):

XSLException Type is: XPathParserException
Message is: A variable reference is allowed in a match pattern or
expression in this context.
pattern = '*[@id != $var]' Remaining tokens are:  ( 'var' ']')
(var-in-xslkey.xsl, line 5, column 54)

Actual Results (1388736 and later):

XPath error: A variable reference is allowed in a match pattern or expression 
in this context.
pattern = '*[@id != $var]' Remaining tokens are:  ( 'var' ']') (Occurred in an 
unknown entity, at line 5, column 5.)
Segmentation fault





--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-752) Recursive xsl:call-template exhausts memory

2013-08-02 Thread Bill Blough (JIRA)

Bill Blough created XALANC-752:
--

 Summary: Recursive xsl:call-template exhausts memory
 Key: XALANC-752
 URL: https://issues.apache.org/jira/browse/XALANC-752
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Debian GNU/Linux
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Critical


Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718315

When using the following template, recursion occurs in an unbounded fashion, 
eventually exhausting all memory.

$ cat test.xsl
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;

xsl:template match=/ name=add
  xsl:call-template name=add/
/xsl:template

/xsl:stylesheet

To reproduce:

$ TestXSLT -in test.xsl -xsl test.xsl

The Xalan executable exhibits the same behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Closed] (XALANJ-2562) showEvento.do in User Mode con redirect participants error

2013-08-18 Thread Michele Vivoda (JIRA)


 [ 
https://issues.apache.org/jira/browse/XALANJ-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michele Vivoda closed XALANJ-2562.
--

Resolution: Invalid

Sorry, used the wrong JIRA.

 showEvento.do in User Mode con redirect participants error
 --

 Key: XALANJ-2562
 URL: https://issues.apache.org/jira/browse/XALANJ-2562
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Reporter: Michele Vivoda
Assignee: Steven J. Hathaway
Priority: Minor
   Original Estimate: 10m
  Remaining Estimate: 10m



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2574) Hung Threads at org.apache.xml.dtm.ref.DTMDefaultBase.findNamespaceContext(Unknown Source)

2013-08-22 Thread Numan Ilyas (JIRA)

Numan Ilyas created XALANJ-2574:
---

 Summary: Hung Threads at 
org.apache.xml.dtm.ref.DTMDefaultBase.findNamespaceContext(Unknown Source)
 Key: XALANJ-2574
 URL: https://issues.apache.org/jira/browse/XALANJ-2574
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Xalan, XPath
Affects Versions: 2.7.1
 Environment: RHEL, WebSphere
Reporter: Numan Ilyas
Assignee: Steven J. Hathaway
Priority: Critical


We are having hung threads in our JVM logs and these threads are consuming all 
the CPU and hence application performance degrades. Our application is running 
on WebSphere. Following is the stack trace for the hung threads.

[8/20/13 10:29:57:982 EDT] 001a ThreadMonitor W   WSVR0605W: Thread 
Migrated.Servlet.Engine.Transports : 1605 (0670) has been active for 
646127 milliseconds and may be hung.  There is/are 1 thread(s) in total in the 
server that may be hung.
at org.apache.xml.dtm.ref.DTMDefaultBase.findNamespaceContext(Unknown 
Source)
at 
org.apache.xml.dtm.ref.DTMDefaultBase.declareNamespaceInContext(Unknown Source)
at org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.addNode(Unknown Source)
at 
org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.processNamespacesAndAttributes(Unknown 
Source)
at org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.nextNode(Unknown Source)
at org.apache.xml.dtm.ref.DTMDefaultBase._nextsib(Unknown Source)
at org.apache.xml.dtm.ref.DTMDefaultBase.getNextSibling(Unknown Source)
at 
org.apache.xml.dtm.ref.DTMDefaultBaseTraversers$ChildTraverser.next(Unknown 
Source)
at org.apache.xpath.axes.AxesWalker.getNextNode(Unknown Source)
at org.apache.xpath.axes.AxesWalker.nextNode(Unknown Source)
at org.apache.xpath.axes.WalkingIterator.nextNode(Unknown Source)
at org.apache.xpath.axes.NodeSequence.nextNode(Unknown Source)
at org.apache.xpath.axes.NodeSequence.runTo(Unknown Source)
at org.apache.xpath.axes.NodeSequence.setRoot(Unknown Source)
at org.apache.xpath.axes.LocPathIterator.execute(Unknown Source)
at org.apache.xpath.XPath.execute(Unknown Source)
at org.apache.xpath.jaxp.XPathExpressionImpl.evaluate(Unknown Source)   

at our code reference
at 
com.ibm._jsp._GetCustomerViewExclusionDetails._jspService(_GetCustomerViewExclusionDetails.java:152)
at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1655)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1595)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:131)
at com.savvion.sbm.websecurity.xss.filter.XSSFilter.doFilter(Unknown 
Source)
at 
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
at com.savvion.sbm.bpmportal.util.GZIPFilter.doFilter(Unknown Source)
at 
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
at com.savvion.sbm.bpmportal.util.EncodingFilter.doFilter(Unknown 
Source)
at 
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:77)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:908)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:932)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:500)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at 
com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:121)
at 
com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionServletWrapper.handleRequest(AbstractJSPExtensionServletWrapper.java:239)
at 
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91)
at 
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:864)
at 
com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583

[jira] [Updated] (XALANJ-2574) Hung Threads at org.apache.xml.dtm.ref.DTMDefaultBase.findNamespaceContext(Unknown Source)

2013-08-22 Thread Numan Ilyas (JIRA)


 [ 
https://issues.apache.org/jira/browse/XALANJ-2574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Numan Ilyas updated XALANJ-2574:


Description: 
We are having hung threads in our JVM logs and these threads are consuming all 
the CPU resources. We've to restart the JVMs everytime this issue occur. 
Unfortunately we aren't able to reproduce the issue and hence we can't provide 
the test case to reproduce. Please see following stack trace copied from JVM 
logs:


[8/20/13 10:29:57:982 EDT] 001a ThreadMonitor W   WSVR0605W: Thread 
Migrated.Servlet.Engine.Transports : 1605 (0670) has been active for 
646127 milliseconds and may be hung.  There is/are 1 thread(s) in total in the 
server that may be hung.
at org.apache.xml.dtm.ref.DTMDefaultBase.findNamespaceContext(Unknown 
Source)
at 
org.apache.xml.dtm.ref.DTMDefaultBase.declareNamespaceInContext(Unknown Source)
at org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.addNode(Unknown Source)
at 
org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.processNamespacesAndAttributes(Unknown 
Source)
at org.apache.xml.dtm.ref.dom2dtm.DOM2DTM.nextNode(Unknown Source)
at org.apache.xml.dtm.ref.DTMDefaultBase._nextsib(Unknown Source)
at org.apache.xml.dtm.ref.DTMDefaultBase.getNextSibling(Unknown Source)
at 
org.apache.xml.dtm.ref.DTMDefaultBaseTraversers$ChildTraverser.next(Unknown 
Source)
at org.apache.xpath.axes.AxesWalker.getNextNode(Unknown Source)
at org.apache.xpath.axes.AxesWalker.nextNode(Unknown Source)
at org.apache.xpath.axes.WalkingIterator.nextNode(Unknown Source)
at org.apache.xpath.axes.NodeSequence.nextNode(Unknown Source)
at org.apache.xpath.axes.NodeSequence.runTo(Unknown Source)
at org.apache.xpath.axes.NodeSequence.setRoot(Unknown Source)
at org.apache.xpath.axes.LocPathIterator.execute(Unknown Source)
at org.apache.xpath.XPath.execute(Unknown Source)
at org.apache.xpath.jaxp.XPathExpressionImpl.evaluate(Unknown Source)   

at our code reference
at 
com.ibm._jsp._GetCustomerViewExclusionDetails._jspService(_GetCustomerViewExclusionDetails.java:152)
at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1655)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1595)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:131)
at com.savvion.sbm.websecurity.xss.filter.XSSFilter.doFilter(Unknown 
Source)
at 
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
at com.savvion.sbm.bpmportal.util.GZIPFilter.doFilter(Unknown Source)
at 
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
at com.savvion.sbm.bpmportal.util.EncodingFilter.doFilter(Unknown 
Source)
at 
com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:188)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:116)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:77)
at 
com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:908)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:932)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:500)
at 
com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at 
com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:121)
at 
com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionServletWrapper.handleRequest(AbstractJSPExtensionServletWrapper.java:239)
at 
com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:91)
at 
com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:864)
at 
com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1583)
at 
com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:186)
at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:455)
at 
com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:384)
at 
com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete

[jira] [Commented] (XALANC-741) Patch for VS 2012

2013-09-14 Thread jan iversen (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANC-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13767453#comment-13767453
 ] 

jan iversen commented on XALANC-741:


Is this still being worked on ?

I need a VS2012 C++ version and if something is missing I can try to finish the 
scripts.

rgds
jan I

 Patch for VS 2012
 -

 Key: XALANC-741
 URL: https://issues.apache.org/jira/browse/XALANC-741
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Microsoft Visual Studio 2012
Reporter: Steven J. Hathaway
Assignee: Steven J. Hathaway
  Labels: patch
 Attachments: ms-scripts.zip, ms-xalan-vs2012.zip


 I am preparing patches to build Xalan-C with MS Studio 2012.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-738) Issue building DoubleSupport.hpp on Solaris with use if isnan


[ 
https://issues.apache.org/jira/browse/XALANC-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776834#comment-13776834
 ] 

Steven J. Hathaway commented on XALANC-738:
---

I have committed the patch to the trunk.

- Steven J. Hathaway

 Issue building DoubleSupport.hpp on Solaris with use if isnan
 -

 Key: XALANC-738
 URL: https://issues.apache.org/jira/browse/XALANC-738
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Solaris 10u10
 gcc 3.2.3
 xerces-c 3.1.1
Reporter: Robert Hillier
Assignee: Steven J. Hathaway
  Labels: build

 When building on Solaris, the compilation of DoubleSupport.hpp fails with 
 message:
 isnan is not in namespace std
 I have been able to work around this my making the following change:
 #if defined(SOLARIS)
 #include math.h
 #endif
 static bool
 isNaN(doubletheNumber)
 {
 #if defined(_MSC_VER)
 return _isnan(theNumber) != 0;
 #elif defined(XALAN_POSIX2_AVAILABLE)  !defined(CYGWIN)  !defined(MINGW)
 #if defined(XALAN_NO_STD_NAMESPACE)
 return isnam(theNumber) != 0;
 #else
 #if defined(SOLARIS)
 return isnan(theNumber) != 0;
 #else
 return std::isnan(theNumber) != 0;
 #endif
 #endif
 #else
 return s_NaN == theNumber;
 #endif
 }
 This fixes this particular problem, but I wanted to be sure I'm not missing 
 something else.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-745) XalanExe unable to do transform on W3C doc types without workaround

[
https://issues.apache.org/jira/browse/XALANC-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776848#comment-13776848
]

Steven J. Hathaway commented on XALANC-745:
---

The underlying Xerces-C has support for user-defined catalogs.
The Xalan-C library has linkages to support Xerces-C capability.

There is no work to my knowledge of creating a default catalog
(entity resolver) that will solve the problem.

The default (entity resolver) relies on the local file system
to acquire system resources and DNS to acquire remote resources.

- Steven J. Hathaway

XalanExe unable to do transform on W3C doc types without workaround
---

Key: XALANC-745
URL: https://issues.apache.org/jira/browse/XALANC-745
Project: XalanC
Issue Type: Bug
Components: XalanC
Affects Versions: 1.10, 1.11
Environment: Issue reproduced on Debian GNU/Linux and Windows XP
using 1.10 and 1.11 binaries.
Reporter: Bill Blough
Assignee: Steven J. Hathaway

Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702225
Since W3C has started blocking some fetches of their documents due to
overuse, it is no longer possible to transform xhtml (or presumably other W3C
doc types) using XalanExe as shipped.
If the source document is edited and the DOCTYPE URL is adjusted to reflect
an existing local or non-W3C-hosted copy of the DTD, then the transform
completes as expected.
I suggest adding functionality to XalanExe that will allow it to make use of
locally installed DTD/XSD catalogs instead of fetching docs from the W3C
website.

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-746) Allow builds for GNU/kFreeBSD


[ 
https://issues.apache.org/jira/browse/XALANC-746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776912#comment-13776912
 ] 

Steven J. Hathaway commented on XALANC-746:
---

Patch submitted to trunk

- Steven J. Hathaway

 Allow builds for GNU/kFreeBSD
 -

 Key: XALANC-746
 URL: https://issues.apache.org/jira/browse/XALANC-746
 Project: XalanC
  Issue Type: Improvement
  Components: XalanC
Affects Versions: 1.11
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Minor
 Attachments: kfreebsd-support.diff


 Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347196
 Allow builds for systems running GNU/kFreeBSD. 
 Patch against 1.11 attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-747) FTBFS when using ld flag --as-needed


[ 
https://issues.apache.org/jira/browse/XALANC-747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776982#comment-13776982
 ] 

Steven J. Hathaway commented on XALANC-747:
---

I will go ahead and apply the diff.

Similar ordering needed to be made on other files - already performed and 
committed.

Steven J. Hathaway

 FTBFS when using ld flag --as-needed
 

 Key: XALANC-747
 URL: https://issues.apache.org/jira/browse/XALANC-747
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.10, 1.11
Reporter: Bill Blough
Assignee: Steven J. Hathaway
 Fix For: 1.11

 Attachments: fix-ftbfs-ld-as-needed.diff


 Reference: http://bugs.debian.org/641289
 Failure to build from source when linking with --as-needed flag.
 Patch against 1.11 attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-745) XalanExe unable to do transform on W3C doc types without workaround

2013-09-25 Thread Bill Blough (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANC-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777200#comment-13777200
 ] 

Bill Blough commented on XALANC-745:



I agree, writing a custom entity resolver would be the way to go if one was 
writing code using Xalan as a library.  But in this case, it's end users that 
are using XalanExe (or possibly TestXSLT) as generic utilities to do 
transformations without writing their own programs.  

Normally the behavior for the default entity resolver should be fine, but now 
that W3C has started blocking requests, transformations fail that otherwise 
wouldn't (due to the remote resources being unavailable).

One possible solution might be to add an optional command line argument that 
would specify a local catalog or cache location that could be checked for 
remote resources prior to the normal DNS lookup and subsequent fetch.





 XalanExe unable to do transform on W3C doc types without workaround
 ---

 Key: XALANC-745
 URL: https://issues.apache.org/jira/browse/XALANC-745
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.10, 1.11
 Environment: Issue reproduced on Debian GNU/Linux and Windows XP 
 using 1.10 and 1.11 binaries.
Reporter: Bill Blough
Assignee: Steven J. Hathaway

 Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702225
 Since W3C has started blocking some fetches of their documents due to 
 overuse, it is no longer possible to transform xhtml (or presumably other W3C 
 doc types) using XalanExe as shipped.
 If the source document is edited and the DOCTYPE URL is adjusted to reflect 
 an existing local or non-W3C-hosted copy of the DTD, then the transform 
 completes as expected.
 I suggest adding functionality to XalanExe that will allow it to make use of 
 locally installed DTD/XSD catalogs instead of fetching docs from the W3C 
 website.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-752) Recursive xsl:call-template exhausts memory

2013-09-25 Thread Bill Blough (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANC-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777202#comment-13777202
 ] 

Bill Blough commented on XALANC-752:


The user that originally reported this stated

Note that xsltproc doesn't have this problem, as libxslt has infinite
template recursion detection (thanks to xsltMaxDepth).

So that is, perhaps, one way to deal with the issue.

 Recursive xsl:call-template exhausts memory
 ---

 Key: XALANC-752
 URL: https://issues.apache.org/jira/browse/XALANC-752
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Debian GNU/Linux
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Critical

 Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718315
 When using the following template, recursion occurs in an unbounded fashion, 
 eventually exhausting all memory.
 $ cat test.xsl
 xsl:stylesheet version=1.0
 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
 xsl:template match=/ name=add
   xsl:call-template name=add/
 /xsl:template
 /xsl:stylesheet
 To reproduce:
 $ TestXSLT -in test.xsl -xsl test.xsl
 The Xalan executable exhibits the same behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-752) Recursive xsl:call-template exhausts memory

2013-09-25 Thread Steven J. Hathaway (JIRA)

[
https://issues.apache.org/jira/browse/XALANC-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1317#comment-1317
]

Steven J. Hathaway commented on XALANC-752:
---

I have some templates that have arbitrary recursion depth
that may break if a fixed recursion limit is enforced. I
prefer to have memory exhaustion failure to be recognized if
the platform is unable to do the needed recursion depth.
It is quite possible for my templates to see hundreds if not
a 1-2 thousand recursions that are legitimate assuming that
hardware resources are available.

There is a possibility when using the pluggable memory manager
of Xerces such that an out-of-memory resource can be detected
and return a non-abortive exception in a graceful manner.
This can help with proper notifications to the parent control
program.

The problem with stack overflow is a different memory
management issue having catastrophic consequences.

I have been trying to review the memory management issues
for several years now and see no easy solution.

I also see no easy programmatic way other than a max-depth hack
to detect an infinite recursion.

- Steven J. Hathaway

Recursive xsl:call-template exhausts memory
---

Key: XALANC-752
URL: https://issues.apache.org/jira/browse/XALANC-752
Project: XalanC
Issue Type: Bug
Components: XalanC
Affects Versions: 1.11
Environment: Debian GNU/Linux
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Critical

Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718315
When using the following template, recursion occurs in an unbounded fashion,
eventually exhausting all memory.
$ cat test.xsl
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=/ name=add
xsl:call-template name=add/
/xsl:template
/xsl:stylesheet
To reproduce:
$ TestXSLT -in test.xsl -xsl test.xsl
The Xalan executable exhibits the same behavior.

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2438) [PATCH] XSLTC ignores XPath predicates in xsl:key elements

2013-10-09 Thread Uwe Schindler (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANJ-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13790619#comment-13790619
 ] 

Uwe Schindler commented on XALANJ-2438:
---

Can we hopefully fix this at some time?

It looks like this bug also affects other use-cases of xsl:key and key(): If 
you load a foreign document with the document() XSL function, all xsl:key 
elements are broken afterwards and important things like the Muenchian Grouping 
cannot be used anymore. I have stylesheets that used this style of grouping 
fine until I added the document() function. The problem here is also that 
buildKeys() is executed twice (on each document() call).

 [PATCH] XSLTC ignores XPath predicates in xsl:key elements
 --

 Key: XALANJ-2438
 URL: https://issues.apache.org/jira/browse/XALANJ-2438
 Project: XalanJ2
  Issue Type: Bug
  Components: XSLTC
Affects Versions: The Latest Development Code
 Environment: Linux and Windows XP with Sun JRE 1.5.0_14, 1.5.0_15, 
 1.6.0_04 and 1.6.0_05
Reporter: Helge Schulz
Priority: Blocker
 Fix For: The Latest Development Code

 Attachments: PredicateInKey.out, 
 PredicateInKey-Xalan-SVN-r889881.patch, PredicateInKey.xml, 
 PredicateInKey.xsl, PredicateInKey-XSLT-Test-1.1.jar, 
 PredicateInKey-XSLT-Test-1.2.jar, PredicateInKey-XSLT-Test-1.3.jar, 
 PredicateInKey-XSLT-Test.jar


 The Xalan XSLT compiler (XSLTC) ignores XPath predicates in xsl:key
 elements since the class 'org.apache.xalan.xsltc.compiler.Stylesheet'
 was rearranged in august 2003 to reorder the compilation of top level
 XSLT elements (including keys) to respect dependencies between global
 XSLT variables and keys. Method 'compileTopLevel' was changed to emit
 code also for key elements and not emit code calling the method generated
 by 'compileBuildKeys'. For this reason the byte code for each key element
 is generated twice: First time into generated method 'buildKeys' from
 'compileBuildKeys' and second time into generated method 'topLevel'
 from 'compileTopLevel'. Method 'buildKeys' is still necessary, because
 it is called by the XSLT 'document' function, if additional input
 documents are loaded later.
 Unfortunately the translate method of some XPath elements expected to
 be called only once and they remove sub elements while their first execution.
 So all XPath predicates get lost in class 
 'org.apache.xalan.xsltc.compiler.FilterExpr'
 and 'org.apache.xalan.xsltc.compiler.Step' by a remove operation on
 the '_predicates' container while the execution from 'compileBuildKeys'.
 So 'compileTopLevel' generates wrong code for all key elements containing
 predicates in their XPath expressions.
 The attached patch changes the 'FilterExpr' and 'Step' class to use an
 index variable to determine the current predicate and to not remove them.
 This patch was tested with the current Subversion version of Xalan
 (last change of Xalan tree in revision 584164) and with Sun JDK 1.5.0_14,
 1.5.0_15, 1.6.0_04 and 1.6.0_05.
 This bug exists also in Sun JRE 1.6 (1.6.0 up to 1.6.0_05) and JRE 1.5
 (since 1.5.0_12 up to 1.5.0_15) in classes
 'com.sun.org.apache.xalan.internal.xsltc.compiler.FilterExpr' and
 'com.sun.org.apache.xalan.internal.xsltc.compiler.Step'. The attached
 test JAR file contains also patches for these versions and fixes in form
 of JAR files to be installed into '../jre/lib/endorsed' directories of
 Sun JRE installations. The last Sun JRE version with correct handling
 of xls:key elements is 1.5.0_11.
 Please add the attached test files to the Xalan test suite. I have
 released them under Apache license  version 2.0.
 Helge Schulz - OpenSHORE.org



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-752) Recursive xsl:call-template exhausts memory

2013-10-14 Thread Vincent Lefevre (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANC-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13794156#comment-13794156
 ] 

Vincent Lefevre commented on XALANC-752:


It seems that libxslt's method is just a heuristic based on the recursion 
depth, which is needed anyway to also avoid finite but huge recursion depth. 
The default maximum depth is 3000, but can be changed by the user, either via 
the API or via the --maxdepth option for the xsltproc command.

The choice for the default is rather arbitrary, as the best choice would depend 
on the environment, but the fact that it is just a default and is configurable 
is sufficient.

More generally, XalanC could also provide an option to limit memory usage, 
possibly as a percentage of physical memory, as the xz compressor/decompressor 
does.

 Recursive xsl:call-template exhausts memory
 ---

 Key: XALANC-752
 URL: https://issues.apache.org/jira/browse/XALANC-752
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Debian GNU/Linux
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Critical

 Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718315
 When using the following template, recursion occurs in an unbounded fashion, 
 eventually exhausting all memory.
 $ cat test.xsl
 xsl:stylesheet version=1.0
 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
 xsl:template match=/ name=add
   xsl:call-template name=add/
 /xsl:template
 /xsl:stylesheet
 To reproduce:
 $ TestXSLT -in test.xsl -xsl test.xsl
 The Xalan executable exhibits the same behavior.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-754) Crash parsing windows file url

2013-10-19 Thread Kelly Graus (JIRA)

Kelly Graus created XALANC-754:
--

 Summary: Crash parsing windows file url
 Key: XALANC-754
 URL: https://issues.apache.org/jira/browse/XALANC-754
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Windows, Visual Studio 2010
Reporter: Kelly Graus
Assignee: Steven J. Hathaway


When parsing a windows file URL (file:///c:/somefile), the XalanParsedURL class 
crashes when parsing the authority. 

Removing one of the slashes after file works around the crash and allows the 
correct file to be accessed, but it's not a valid URL. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Issue Comment Deleted] (XALANC-754) Crash parsing windows file url

2013-10-21 Thread Kelly Graus (JIRA)


 [ 
https://issues.apache.org/jira/browse/XALANC-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelly Graus updated XALANC-754:
---

Comment: was deleted

(was: After looking further into the issue, I believe my workaround only works 
because I implement a custom EntityResolver that can deal with malformed URLs.)

 Crash parsing windows file url
 --

 Key: XALANC-754
 URL: https://issues.apache.org/jira/browse/XALANC-754
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Windows, Visual Studio 2010
Reporter: Kelly Graus
Assignee: Steven J. Hathaway

 When parsing a windows file URL (file:///c:/somefile), the XalanParsedURL 
 class crashes when parsing the authority. 
 Removing one of the slashes after file works around the crash and allows 
 the correct file to be accessed, but it's not a valid URL. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANC-754) Crash parsing windows file url

2013-10-21 Thread Kelly Graus (JIRA)


 [ 
https://issues.apache.org/jira/browse/XALANC-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelly Graus updated XALANC-754:
---

Attachment: XalanDOMString.hpp
XalanParsedURI.cpp

 Crash parsing windows file url
 --

 Key: XALANC-754
 URL: https://issues.apache.org/jira/browse/XALANC-754
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Windows, Visual Studio 2010
Reporter: Kelly Graus
Assignee: Steven J. Hathaway
 Attachments: XalanDOMString.hpp, XalanParsedURI.cpp


 When parsing a windows file URL (file:///c:/somefile), the XalanParsedURL 
 class crashes when parsing the authority. 
 Removing one of the slashes after file works around the crash and allows 
 the correct file to be accessed, but it's not a valid URL. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-754) Crash parsing windows file url

2013-10-21 Thread Kelly Graus (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANC-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800945#comment-13800945
 ] 

Kelly Graus commented on XALANC-754:


Looking into this further, my workaround only partially worked due to the fact 
I had implemented a custom EntityResolver that could deal with malformed URLs.

However, there are still several problems related to Xerces throwing 
MalformedURLExceptions whenever it encounters these URLs.

I was able to implement a fix in Xalan, but am unsure how to go about 
committing it (or if it's even worthy to be committed, I have by no means 
done more than cursory testing on it).  I will attach the two files that I 
changed.

 Crash parsing windows file url
 --

 Key: XALANC-754
 URL: https://issues.apache.org/jira/browse/XALANC-754
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Windows, Visual Studio 2010
Reporter: Kelly Graus
Assignee: Steven J. Hathaway
 Attachments: XalanDOMString.hpp, XalanParsedURI.cpp


 When parsing a windows file URL (file:///c:/somefile), the XalanParsedURL 
 class crashes when parsing the authority. 
 Removing one of the slashes after file works around the crash and allows 
 the correct file to be accessed, but it's not a valid URL. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-752) Recursive xsl:call-template exhausts memory

2014-02-01 Thread Bill Blough (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANC-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13888780#comment-13888780
 ] 

Bill Blough commented on XALANC-752:



Due to changes in Debian release policy, this issue has caused Xalan to be 
dropped from Debian testing.  Generally speaking, if Xalan is to be included in 
the next Debian release, this issue will need to be resolved before the freeze 
occurs later this year (Sept/Oct).

I understand that resources are limited and that it may be some time before the 
Xalan team can deal with this particular issue.  I was just wondering if it has 
been discussed and whether or not it is on the agenda.

 Recursive xsl:call-template exhausts memory
 ---

 Key: XALANC-752
 URL: https://issues.apache.org/jira/browse/XALANC-752
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Debian GNU/Linux
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Critical

 Forwarded from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718315
 When using the following template, recursion occurs in an unbounded fashion, 
 eventually exhausting all memory.
 $ cat test.xsl
 xsl:stylesheet version=1.0
 xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
 xsl:template match=/ name=add
   xsl:call-template name=add/
 /xsl:template
 /xsl:stylesheet
 To reproduce:
 $ TestXSLT -in test.xsl -xsl test.xsl
 The Xalan executable exhibits the same behavior.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2579) 'apply-templates select' fails to extract the select expression in trace mode

2014-03-25 Thread Ronan Mulvaney (JIRA)

Ronan Mulvaney created XALANJ-2579:
--

 Summary: 'apply-templates select' fails to extract the select 
expression in trace mode
 Key: XALANJ-2579
 URL: https://issues.apache.org/jira/browse/XALANJ-2579
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Trace-facility
Affects Versions: 2.7.1
Reporter: Ronan Mulvaney
Assignee: Steven J. Hathaway
Priority: Minor


Similar to a previous bug 
http://mail-archives.apache.org/mod_mbox/xml-xalan-dev/200403.mbox/%3c20040308190022.16423.qm...@nagoya.betaversion.org%3E
 where the select expression was not available in the for-each function.

It is also on available in the apply-templates function.
The problem seems to lie with the ElemApplyTemplates class and the way this 
fires it's SelectedEvent versus the code in the ElemForEach class where the fix 
was made.
It would look like this fix should have been applied to more than just a single 
class initially.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Resolved] (XALANJ-2435) Use of secure processing feature should disable some output properties


 [ 
https://issues.apache.org/jira/browse/XALANJ-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved XALANJ-2435.
--

   Resolution: Fixed
Fix Version/s: 2.7.2
 Assignee: Gary Gregory

http://www.ocert.org/advisories/ocert-2014-002.html

Fixed in SVN branch 
https://svn.apache.org/repos/asf/xalan/java/branches/xalan-j_2_7_1_maint

 Use of secure processing feature should disable some output properties
 --

 Key: XALANJ-2435
 URL: https://issues.apache.org/jira/browse/XALANJ-2435
 Project: XalanJ2
  Issue Type: Bug
Affects Versions: 2.7.1
Reporter: Steve Jones
Assignee: Gary Gregory
 Fix For: 2.7.2

 Attachments: TestXslt.java


 When using the FEATURE_SECURE_PROCESSING 
 (http://javax.xml.XMLConstants/feature/secure-processing;) on a 
 TransformerFactory it seems appropriate that the output properties:
   {http://xml.apache.org/xalan}content-handler 
   {http://xml.apache.org/xalan}entities
   {http://xml.apache.org/xslt}content-handler 
   {http://xml.apache.org/xslt}entities
 should be ignored (see 
 http://xml.apache.org/xalan-j/usagepatterns.html#outputprops)
 These properties can be used to load an arbitrary class or access an 
 arbitrary URL/resource so are problematic when secure processing is desired.
xsl:output xalan:content-handler=org.example.BadClass ...
xsl:output xalan:entities=http://example.org/reallyLargeFile.bin; ...
 These features could be used to load a class that had undesirable 
 side-effects or to load a large file and exhaust memory, etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2580) Update 2.7.x branch to Xerces 2.11.0 from 2.9.0 (and matching xml-apis)

Gary Gregory created XALANJ-2580:


 Summary: Update 2.7.x branch to Xerces 2.11.0 from 2.9.0 (and 
matching xml-apis)
 Key: XALANJ-2580
 URL: https://issues.apache.org/jira/browse/XALANJ-2580
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: DOM, JAXP, SAX
Affects Versions: 2.7.1
 Environment: java version 1.3.1_28
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_28-b03)
Java HotSpot(TM) Client VM (build 1.3.1_28-b03, mixed mode)

Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.7.2


Upgraded xercesImpl.jar to 2.11.0 and xml-apis.jar code to 1.4.01 (from the  
Xerces distro).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Resolved] (XALANJ-2580) Update 2.7.x branch to Xerces 2.11.0 from 2.9.0 (and matching xml-apis)


 [ 
https://issues.apache.org/jira/browse/XALANJ-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved XALANJ-2580.
--

Resolution: Fixed

Fixed in SVN.

 Update 2.7.x branch to Xerces 2.11.0 from 2.9.0 (and matching xml-apis)
 ---

 Key: XALANJ-2580
 URL: https://issues.apache.org/jira/browse/XALANJ-2580
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
  Components: DOM, JAXP, SAX
Affects Versions: 2.7.1
 Environment: java version 1.3.1_28
 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_28-b03)
 Java HotSpot(TM) Client VM (build 1.3.1_28-b03, mixed mode)
 Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.7.2


 Upgraded xercesImpl.jar to 2.11.0 and xml-apis.jar code to 1.4.01 (from the  
 Xerces distro).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2581) Minor performance improvement: Use String.lastIndexOf(int) instead of String.lastIndexOf(String).

Gary Gregory created XALANJ-2581:


 Summary: Minor performance improvement: Use 
String.lastIndexOf(int) instead of String.lastIndexOf(String).
 Key: XALANJ-2581
 URL: https://issues.apache.org/jira/browse/XALANJ-2581
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
Affects Versions: 2.7.1
Reporter: Gary Gregory
Assignee: Steven J. Hathaway
 Fix For: 2.7.2


Minor performance improvement: Use String.lastIndexOf(int) instead of 
String.lastIndexOf(String).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Resolved] (XALANJ-2581) Minor performance improvement: Use String.lastIndexOf(int) instead of String.lastIndexOf(String).


 [ 
https://issues.apache.org/jira/browse/XALANJ-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved XALANJ-2581.
--

Resolution: Fixed

Fixed in SVN.

 Minor performance improvement: Use String.lastIndexOf(int) instead of 
 String.lastIndexOf(String).
 -

 Key: XALANJ-2581
 URL: https://issues.apache.org/jira/browse/XALANJ-2581
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Affects Versions: 2.7.1
Reporter: Gary Gregory
Assignee: Steven J. Hathaway
 Fix For: 2.7.2


 Minor performance improvement: Use String.lastIndexOf(int) instead of 
 String.lastIndexOf(String).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2546) xsl:sort lang attribute ignores parameter value, only hard-coding works


 [ 
https://issues.apache.org/jira/browse/XALANJ-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated XALANJ-2546:
-

Fix Version/s: 2.7.2

 xsl:sort lang attribute ignores parameter value, only hard-coding works
 ---

 Key: XALANJ-2546
 URL: https://issues.apache.org/jira/browse/XALANJ-2546
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
  Components: Xalan
Affects Versions: 2.7.1
 Environment: java version 1.6.0_20, Xalan 2.7.1
Reporter: Don Smith
 Fix For: 2.7.2

 Attachments: XALANJ-2546.diff, sorting-example.zip


 I have an XSL stylesheet that uses xsl:sort for a list of names. I added the 
 lang attribute to the sort, using a variable passed to the stylesheet for its 
 value:   lang={$locale}. When sorting a list of Russian names, the ordering 
 is incorrect. I can see that the parameter value is present and correct in 
 the stylesheet as it executes by using an xsl:message statement. When I 
 hard-code the value of lang to ru (lang=ru), the sort works correctly. This 
 defect  cause improper sorting in Russian and Polish, a defect in our 
 application.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Resolved] (XALANJ-2583) org.apache.xml.utils.NodeVector.sort: Fix an averaging computation that could overflow for large values.


 [ 
https://issues.apache.org/jira/browse/XALANJ-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved XALANJ-2583.
--

Resolution: Fixed
  Assignee: Gary Gregory  (was: Steven J. Hathaway)

Fix in SVN r1225445.

 org.apache.xml.utils.NodeVector.sort: Fix an averaging computation that could 
 overflow for large values.
 

 Key: XALANJ-2583
 URL: https://issues.apache.org/jira/browse/XALANJ-2583
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Affects Versions: 2.7.1
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.7.2


 org.apache.xml.utils.NodeVector.sort: Fix an averaging computation that could 
 overflow for large values.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2583) org.apache.xml.utils.NodeVector.sort: Fix an averaging computation that could overflow for large values.


 [ 
https://issues.apache.org/jira/browse/XALANJ-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated XALANJ-2583:
-

Description: 
Fix an averaging computation that could overflow for large values in:
- org.apache.xml.utils.NodeVector.sort()
- org.apache.xml.dtm.ref.DTMDefaultBase.findGTE()

  was:org.apache.xml.utils.NodeVector.sort: Fix an averaging computation that 
could overflow for large values.


 org.apache.xml.utils.NodeVector.sort: Fix an averaging computation that could 
 overflow for large values.
 

 Key: XALANJ-2583
 URL: https://issues.apache.org/jira/browse/XALANJ-2583
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Affects Versions: 2.7.1
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 2.7.2


 Fix an averaging computation that could overflow for large values in:
 - org.apache.xml.utils.NodeVector.sort()
 - org.apache.xml.dtm.ref.DTMDefaultBase.findGTE()



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2584) EXSLT function Date:Date throws IndexOutOfBounds Exception on empty input

2014-05-01 Thread Philip Miess (JIRA)

Philip Miess created XALANJ-2584:


 Summary: EXSLT function Date:Date throws IndexOutOfBounds 
Exception on empty input
 Key: XALANJ-2584
 URL: https://issues.apache.org/jira/browse/XALANJ-2584
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Xalan
Affects Versions: 2.7.2
Reporter: Philip Miess
Assignee: Steven J. Hathaway
Priority: Minor


When running the following XSL file Xalan-J throws 
bq. java.lang.StringIndexOutOfBoundsException: String index out of range: 0 - 
String index out of range: 0
As long as the root node does not have an attribute named anAttribute.


Expected output is an single root node

[ExsltDatetime.html|https://xalan.apache.org/xalan-j/apidocs/org/apache/xalan/lib/ExsltDatetime.html#date(java.lang.String)]
 indicates that it should produce an empty string instead of throwing

bq. If the argument is not in either of these formats, date:date returns an 
empty string ('')
Saxon produces the expected output.

If the null check where moved to the start of the date function it world work 
as specified.

h4. The files used to reproduce this problem

h5. The transform file

{code:xml|title=Transform.xsl}
?xml version=1.0 encoding=UTF-8?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:exsl=http://exslt.org;
xmlns:date=http://exslt.org/dates-and-times;
extension-element-prefixes=date exsl
version=1.0
xsl:template match=/
xsl:element name=root
xsl:value-of select=date:date(root/@anAttribute)/
/xsl:element
/xsl:template
/xsl:stylesheet
{code}

h5. An input file that works

{code:xml|title=InputSuccess.xml}
?xml version=1.0 encoding=UTF-8?
root anAttribute=present/
{code}

h5. An input file that causes an StringIndexOutOfBoundsException

{code:xml|title=InputFailure.xml}
?xml version=1.0 encoding=UTF-8?
root /
{code}




--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-756) FormatterToXML throws exception for valid XML

2014-07-23 Thread Andrei Gheorghe (JIRA)

Andrei Gheorghe created XALANC-756:
--

 Summary: FormatterToXML throws exception for valid XML
 Key: XALANC-756
 URL: https://issues.apache.org/jira/browse/XALANC-756
 Project: XalanC
  Issue Type: Bug
Reporter: Andrei Gheorghe
Assignee: Steven J. Hathaway


Xalan-C++ throws SAXException for this XML: ?xml version=1.0 
encoding=UTF-8?elem attr=#xA;/
This XML is valid according to all the validators I have tried.
This issue can be reproduced using the following test program.
I also supplied a patch to show where the problem originates and which seems to 
solve the issue.

{code:title=test.cpp|borderStyle=solid}
#include xercesc/util/PlatformUtils.hpp
#include xercesc/framework/MemBufInputSource.hpp
#include xercesc/parsers/XercesDOMParser.hpp

#include xalanc/XercesParserLiaison/XercesDocumentWrapper.hpp
#include xalanc/PlatformSupport/XalanStdOutputStream.hpp
#include xalanc/PlatformSupport/XalanOutputStreamPrintWriter.hpp
#include xalanc/XMLSupport/FormatterToXML.hpp
#include xalanc/XMLSupport/FormatterTreeWalker.hpp

#include sstream
#include iostream

XERCES_CPP_NAMESPACE_USE
XALAN_CPP_NAMESPACE_USE

using namespace std;

int main()
{
try 
{
XMLPlatformUtils::Initialize();

string testXML = ?xml version=\1.0\ 
encoding=\UTF-8\?elem attr=\#xA;\/;
MemBufInputSource bufferMemSource( ( const XMLByte* 
)testXML.c_str(), testXML.size(), testXML, false );
XercesDOMParser parser;
parser.parse(bufferMemSource);
XercesDocumentWrapper docWrapper( 
*XMLPlatformUtils::fgMemoryManager, parser.getDocument(), true, true, true );

XalanStdOutputStream stream( cout );
XalanOutputStreamPrintWriter printWriter( stream );
FormatterToXML formatter( printWriter );
FormatterTreeWalker walker( formatter );

formatter.setShouldWriteXMLHeader( false );
formatter.startDocument();
walker.traverseSubtree( docWrapper ); //throws SAXException: 
'A' is an invalid Unicode scalar value.
formatter.endDocument();
}
catch ( const exception )
{}

return 0;
}
{code}

{code}
Index: src/xalanc/XMLSupport/FormatterToXML.cpp
===
--- src/xalanc/XMLSupport/FormatterToXML.cpp(revision 1612825)
+++ src/xalanc/XMLSupport/FormatterToXML.cpp(working copy)
@@ -910,7 +910,7 @@
 {
 if(ch  0x20 )
 {
-if(m_isXML1_1)
+if(ch == 0x9 || ch == 0xA || ch == 0xD || m_isXML1_1)
 {
 writeNumberedEntityReference(ch);
 }
{code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANC-756) FormatterToXML throws exception for valid XML

2014-07-23 Thread Andrei Gheorghe (JIRA)


 [ 
https://issues.apache.org/jira/browse/XALANC-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrei Gheorghe updated XALANC-756:
---

Description: 
Xalan-C++ throws SAXException for this XML:
{code}?xml version=1.0 encoding=UTF-8?elem attr=#xA;/{code}
This XML is valid according to all the validators I have tried.
This issue can be reproduced using the following test program.
I also supplied a patch to show where the problem originates and which seems to 
solve the issue.

{code:title=test.cpp|borderStyle=solid}
#include xercesc/util/PlatformUtils.hpp
#include xercesc/framework/MemBufInputSource.hpp
#include xercesc/parsers/XercesDOMParser.hpp

#include xalanc/XercesParserLiaison/XercesDocumentWrapper.hpp
#include xalanc/PlatformSupport/XalanStdOutputStream.hpp
#include xalanc/PlatformSupport/XalanOutputStreamPrintWriter.hpp
#include xalanc/XMLSupport/FormatterToXML.hpp
#include xalanc/XMLSupport/FormatterTreeWalker.hpp

#include sstream
#include iostream

XERCES_CPP_NAMESPACE_USE
XALAN_CPP_NAMESPACE_USE

using namespace std;

int main()
{
try 
{
XMLPlatformUtils::Initialize();

string testXML = ?xml version=\1.0\ 
encoding=\UTF-8\?elem attr=\#xA;\/;
MemBufInputSource bufferMemSource( ( const XMLByte* 
)testXML.c_str(), testXML.size(), testXML, false );
XercesDOMParser parser;
parser.parse(bufferMemSource);
XercesDocumentWrapper docWrapper( 
*XMLPlatformUtils::fgMemoryManager, parser.getDocument(), true, true, true );

XalanStdOutputStream stream( cout );
XalanOutputStreamPrintWriter printWriter( stream );
FormatterToXML formatter( printWriter );
FormatterTreeWalker walker( formatter );

formatter.setShouldWriteXMLHeader( false );
formatter.startDocument();
walker.traverseSubtree( docWrapper ); //throws SAXException: 
'A' is an invalid Unicode scalar value.
formatter.endDocument();
}
catch ( const exception )
{}

return 0;
}
{code}

{code}
Index: src/xalanc/XMLSupport/FormatterToXML.cpp
===
--- src/xalanc/XMLSupport/FormatterToXML.cpp(revision 1612825)
+++ src/xalanc/XMLSupport/FormatterToXML.cpp(working copy)
@@ -910,7 +910,7 @@
 {
 if(ch  0x20 )
 {
-if(m_isXML1_1)
+if(ch == 0x9 || ch == 0xA || ch == 0xD || m_isXML1_1)
 {
 writeNumberedEntityReference(ch);
 }
{code}

  was:
Xalan-C++ throws SAXException for this XML: ?xml version=1.0 
encoding=UTF-8?elem attr=#xA;/
This XML is valid according to all the validators I have tried.
This issue can be reproduced using the following test program.
I also supplied a patch to show where the problem originates and which seems to 
solve the issue.

{code:title=test.cpp|borderStyle=solid}
#include xercesc/util/PlatformUtils.hpp
#include xercesc/framework/MemBufInputSource.hpp
#include xercesc/parsers/XercesDOMParser.hpp

#include xalanc/XercesParserLiaison/XercesDocumentWrapper.hpp
#include xalanc/PlatformSupport/XalanStdOutputStream.hpp
#include xalanc/PlatformSupport/XalanOutputStreamPrintWriter.hpp
#include xalanc/XMLSupport/FormatterToXML.hpp
#include xalanc/XMLSupport/FormatterTreeWalker.hpp

#include sstream
#include iostream

XERCES_CPP_NAMESPACE_USE
XALAN_CPP_NAMESPACE_USE

using namespace std;

int main()
{
try 
{
XMLPlatformUtils::Initialize();

string testXML = ?xml version=\1.0\ 
encoding=\UTF-8\?elem attr=\#xA;\/;
MemBufInputSource bufferMemSource( ( const XMLByte* 
)testXML.c_str(), testXML.size(), testXML, false );
XercesDOMParser parser;
parser.parse(bufferMemSource);
XercesDocumentWrapper docWrapper( 
*XMLPlatformUtils::fgMemoryManager, parser.getDocument(), true, true, true );

XalanStdOutputStream stream( cout );
XalanOutputStreamPrintWriter printWriter( stream );
FormatterToXML formatter( printWriter );
FormatterTreeWalker walker( formatter );

formatter.setShouldWriteXMLHeader( false );
formatter.startDocument();
walker.traverseSubtree( docWrapper ); //throws SAXException: 
'A' is an invalid Unicode scalar value.
formatter.endDocument();
}
catch ( const exception )
{}

return 0;
}
{code}

{code}
Index: src/xalanc/XMLSupport/FormatterToXML.cpp
===
--- src/xalanc/XMLSupport/FormatterToXML.cpp(revision 1612825)
+++ src/xalanc/XMLSupport/FormatterToXML.cpp

[jira] [Created] (XALANJ-2589) ObjectFactory is reloading classes over-and-over causing performance issues with XPATH.

2014-07-24 Thread brian yoder (JIRA)

brian yoder created XALANJ-2589:
---

 Summary: ObjectFactory is reloading classes over-and-over causing 
performance issues with XPATH.
 Key: XALANJ-2589
 URL: https://issues.apache.org/jira/browse/XALANJ-2589
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
Affects Versions: 2.7.2
 Environment: Glassfish 3.1 with JDK 1.6 u37
Reporter: brian yoder
Assignee: Steven J. Hathaway


I have done some performance benchmarking on XPath, and found that the 
ObjectFactory kept calling findProviderClass, which has code that is calling 
the following:

providerClass = cl.loadClass(className);

This is VERY inefficient, and is causing a severe bottleneck.  If i comment 
this code out, and instead use the following I see a significant performance 
improvement.

Class providerClass = Class.forName(className);

I am running on Glassfish 3.1 - and the bottlneck is really bad because my JAR 
files were on SAN, so this code is running very slow.

// Here is the code which I commented out, and rely ONLY on the Class.forName 
method.  Not sure why the other stuff is needed, maybe only to support older 
JVM's?

/**
 * Find a Class using the specified ClassLoader
 */ 
static Class findProviderClass(String className, ClassLoader cl,
   boolean doFallback)
throws ClassNotFoundException, ConfigurationError
{   
//throw security exception if the calling thread is not allowed to 
access the
//class. Restrict the access to the package classes as specified in 
java.security policy.
SecurityManager security = System.getSecurityManager();
try{
if (security != null){
final int lastDot = className.lastIndexOf('.');
String packageName = className;
if (lastDot != -1) packageName = className.substring(0, 
lastDot);
security.checkPackageAccess(packageName);
 }   
}catch(SecurityException e){
throw e;
}
   
Class providerClass = Class.forName(className);
/*
if (cl == null) {
// XXX Use the bootstrap ClassLoader.  There is no way to
// load a class using the bootstrap ClassLoader that works
// in both JDK 1.1 and Java 2.  However, this should still
// work b/c the following should be true:
//
// (cl == null) iff current ClassLoader == null
//
// Thus Class.forName(String) will use the current
// ClassLoader which will be the bootstrap ClassLoader.
providerClass = Class.forName(className);
} else {
try {
providerClass = cl.loadClass(className);
} catch (ClassNotFoundException x) {
if (doFallback) {
// Fall back to current classloader
ClassLoader current = ObjectFactory.class.getClassLoader();
if (current == null) {
providerClass = Class.forName(className);
} else if (cl != current) {
cl = current;
providerClass = cl.loadClass(className);
} else {
throw x;
}
} else {
throw x;
}
}
}
*/
return providerClass;
}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2589) ObjectFactory is reloading classes over-and-over causing performance issues with XPATH.

2014-08-08 Thread Gary Gregory (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANJ-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091055#comment-14091055
 ] 

Gary Gregory commented on XALANJ-2589:
--

Hello,

Could you please provide code changes in unified diff format (aka a patch file).

Gary

 ObjectFactory is reloading classes over-and-over causing performance issues 
 with XPATH.
 ---

 Key: XALANJ-2589
 URL: https://issues.apache.org/jira/browse/XALANJ-2589
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Affects Versions: 2.7.2
 Environment: Glassfish 3.1 with JDK 1.6 u37
Reporter: brian yoder
Assignee: Steven J. Hathaway

 I have done some performance benchmarking on XPath, and found that the 
 ObjectFactory kept calling findProviderClass, which has code that is calling 
 the following:
 providerClass = cl.loadClass(className);
 This is VERY inefficient, and is causing a severe bottleneck.  If i comment 
 this code out, and instead use the following I see a significant performance 
 improvement.
 Class providerClass = Class.forName(className);
 I am running on Glassfish 3.1 - and the bottlneck is really bad because my 
 JAR files were on SAN, so this code is running very slow.
 // Here is the code which I commented out, and rely ONLY on the Class.forName 
 method.  Not sure why the other stuff is needed, maybe only to support older 
 JVM's?
 /**
  * Find a Class using the specified ClassLoader
  */ 
 static Class findProviderClass(String className, ClassLoader cl,
boolean doFallback)
 throws ClassNotFoundException, ConfigurationError
 {   
 //throw security exception if the calling thread is not allowed to 
 access the
 //class. Restrict the access to the package classes as specified in 
 java.security policy.
 SecurityManager security = System.getSecurityManager();
 try{
 if (security != null){
 final int lastDot = className.lastIndexOf('.');
 String packageName = className;
 if (lastDot != -1) packageName = className.substring(0, 
 lastDot);
 security.checkPackageAccess(packageName);
  }   
 }catch(SecurityException e){
 throw e;
 }

 Class providerClass = Class.forName(className);
 /*
 if (cl == null) {
 // XXX Use the bootstrap ClassLoader.  There is no way to
 // load a class using the bootstrap ClassLoader that works
 // in both JDK 1.1 and Java 2.  However, this should still
 // work b/c the following should be true:
 //
 // (cl == null) iff current ClassLoader == null
 //
 // Thus Class.forName(String) will use the current
 // ClassLoader which will be the bootstrap ClassLoader.
 providerClass = Class.forName(className);
 } else {
 try {
 providerClass = cl.loadClass(className);
 } catch (ClassNotFoundException x) {
 if (doFallback) {
 // Fall back to current classloader
 ClassLoader current = 
 ObjectFactory.class.getClassLoader();
 if (current == null) {
 providerClass = Class.forName(className);
 } else if (cl != current) {
 cl = current;
 providerClass = cl.loadClass(className);
 } else {
 throw x;
 }
 } else {
 throw x;
 }
 }
 }
   */
 return providerClass;
 }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2589) ObjectFactory is reloading classes over-and-over causing performance issues with XPATH.


 [ 
https://issues.apache.org/jira/browse/XALANJ-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

brian yoder updated XALANJ-2589:


Attachment: ObjectFactory.java

 ObjectFactory is reloading classes over-and-over causing performance issues 
 with XPATH.
 ---

 Key: XALANJ-2589
 URL: https://issues.apache.org/jira/browse/XALANJ-2589
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Affects Versions: 2.7.2
 Environment: Glassfish 3.1 with JDK 1.6 u37
Reporter: brian yoder
Assignee: Steven J. Hathaway
 Attachments: ObjectFactory.java


 I have done some performance benchmarking on XPath, and found that the 
 ObjectFactory kept calling findProviderClass, which has code that is calling 
 the following:
 providerClass = cl.loadClass(className);
 This is VERY inefficient, and is causing a severe bottleneck.  If i comment 
 this code out, and instead use the following I see a significant performance 
 improvement.
 Class providerClass = Class.forName(className);
 I am running on Glassfish 3.1 - and the bottlneck is really bad because my 
 JAR files were on SAN, so this code is running very slow.
 // Here is the code which I commented out, and rely ONLY on the Class.forName 
 method.  Not sure why the other stuff is needed, maybe only to support older 
 JVM's?
 /**
  * Find a Class using the specified ClassLoader
  */ 
 static Class findProviderClass(String className, ClassLoader cl,
boolean doFallback)
 throws ClassNotFoundException, ConfigurationError
 {   
 //throw security exception if the calling thread is not allowed to 
 access the
 //class. Restrict the access to the package classes as specified in 
 java.security policy.
 SecurityManager security = System.getSecurityManager();
 try{
 if (security != null){
 final int lastDot = className.lastIndexOf('.');
 String packageName = className;
 if (lastDot != -1) packageName = className.substring(0, 
 lastDot);
 security.checkPackageAccess(packageName);
  }   
 }catch(SecurityException e){
 throw e;
 }

 Class providerClass = Class.forName(className);
 /*
 if (cl == null) {
 // XXX Use the bootstrap ClassLoader.  There is no way to
 // load a class using the bootstrap ClassLoader that works
 // in both JDK 1.1 and Java 2.  However, this should still
 // work b/c the following should be true:
 //
 // (cl == null) iff current ClassLoader == null
 //
 // Thus Class.forName(String) will use the current
 // ClassLoader which will be the bootstrap ClassLoader.
 providerClass = Class.forName(className);
 } else {
 try {
 providerClass = cl.loadClass(className);
 } catch (ClassNotFoundException x) {
 if (doFallback) {
 // Fall back to current classloader
 ClassLoader current = 
 ObjectFactory.class.getClassLoader();
 if (current == null) {
 providerClass = Class.forName(className);
 } else if (cl != current) {
 cl = current;
 providerClass = cl.loadClass(className);
 } else {
 throw x;
 }
 } else {
 throw x;
 }
 }
 }
   */
 return providerClass;
 }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2589) ObjectFactory is reloading classes over-and-over causing performance issues with XPATH.


[ 
https://issues.apache.org/jira/browse/XALANJ-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091659#comment-14091659
 ] 

brian yoder commented on XALANJ-2589:
-

I have added the updated file - to attachments.  Not sure how to do the patch 
file or diff format you are asking for.

 ObjectFactory is reloading classes over-and-over causing performance issues 
 with XPATH.
 ---

 Key: XALANJ-2589
 URL: https://issues.apache.org/jira/browse/XALANJ-2589
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Affects Versions: 2.7.2
 Environment: Glassfish 3.1 with JDK 1.6 u37
Reporter: brian yoder
Assignee: Steven J. Hathaway
 Attachments: ObjectFactory.java


 I have done some performance benchmarking on XPath, and found that the 
 ObjectFactory kept calling findProviderClass, which has code that is calling 
 the following:
 providerClass = cl.loadClass(className);
 This is VERY inefficient, and is causing a severe bottleneck.  If i comment 
 this code out, and instead use the following I see a significant performance 
 improvement.
 Class providerClass = Class.forName(className);
 I am running on Glassfish 3.1 - and the bottlneck is really bad because my 
 JAR files were on SAN, so this code is running very slow.
 // Here is the code which I commented out, and rely ONLY on the Class.forName 
 method.  Not sure why the other stuff is needed, maybe only to support older 
 JVM's?
 /**
  * Find a Class using the specified ClassLoader
  */ 
 static Class findProviderClass(String className, ClassLoader cl,
boolean doFallback)
 throws ClassNotFoundException, ConfigurationError
 {   
 //throw security exception if the calling thread is not allowed to 
 access the
 //class. Restrict the access to the package classes as specified in 
 java.security policy.
 SecurityManager security = System.getSecurityManager();
 try{
 if (security != null){
 final int lastDot = className.lastIndexOf('.');
 String packageName = className;
 if (lastDot != -1) packageName = className.substring(0, 
 lastDot);
 security.checkPackageAccess(packageName);
  }   
 }catch(SecurityException e){
 throw e;
 }

 Class providerClass = Class.forName(className);
 /*
 if (cl == null) {
 // XXX Use the bootstrap ClassLoader.  There is no way to
 // load a class using the bootstrap ClassLoader that works
 // in both JDK 1.1 and Java 2.  However, this should still
 // work b/c the following should be true:
 //
 // (cl == null) iff current ClassLoader == null
 //
 // Thus Class.forName(String) will use the current
 // ClassLoader which will be the bootstrap ClassLoader.
 providerClass = Class.forName(className);
 } else {
 try {
 providerClass = cl.loadClass(className);
 } catch (ClassNotFoundException x) {
 if (doFallback) {
 // Fall back to current classloader
 ClassLoader current = 
 ObjectFactory.class.getClassLoader();
 if (current == null) {
 providerClass = Class.forName(className);
 } else if (cl != current) {
 cl = current;
 providerClass = cl.loadClass(className);
 } else {
 throw x;
 }
 } else {
 throw x;
 }
 }
 }
   */
 return providerClass;
 }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2589) ObjectFactory is reloading classes over-and-over causing performance issues with XPATH.


 [ 
https://issues.apache.org/jira/browse/XALANJ-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

brian yoder updated XALANJ-2589:


Attachment: ObjectFactory.java

New version with bug fix

 ObjectFactory is reloading classes over-and-over causing performance issues 
 with XPATH.
 ---

 Key: XALANJ-2589
 URL: https://issues.apache.org/jira/browse/XALANJ-2589
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Affects Versions: 2.7.2
 Environment: Glassfish 3.1 with JDK 1.6 u37
Reporter: brian yoder
Assignee: Steven J. Hathaway
 Attachments: ObjectFactory.java


 I have done some performance benchmarking on XPath, and found that the 
 ObjectFactory kept calling findProviderClass, which has code that is calling 
 the following:
 providerClass = cl.loadClass(className);
 This is VERY inefficient, and is causing a severe bottleneck.  If i comment 
 this code out, and instead use the following I see a significant performance 
 improvement.
 Class providerClass = Class.forName(className);
 I am running on Glassfish 3.1 - and the bottlneck is really bad because my 
 JAR files were on SAN, so this code is running very slow.
 // Here is the code which I commented out, and rely ONLY on the Class.forName 
 method.  Not sure why the other stuff is needed, maybe only to support older 
 JVM's?
 /**
  * Find a Class using the specified ClassLoader
  */ 
 static Class findProviderClass(String className, ClassLoader cl,
boolean doFallback)
 throws ClassNotFoundException, ConfigurationError
 {   
 //throw security exception if the calling thread is not allowed to 
 access the
 //class. Restrict the access to the package classes as specified in 
 java.security policy.
 SecurityManager security = System.getSecurityManager();
 try{
 if (security != null){
 final int lastDot = className.lastIndexOf('.');
 String packageName = className;
 if (lastDot != -1) packageName = className.substring(0, 
 lastDot);
 security.checkPackageAccess(packageName);
  }   
 }catch(SecurityException e){
 throw e;
 }

 Class providerClass = Class.forName(className);
 /*
 if (cl == null) {
 // XXX Use the bootstrap ClassLoader.  There is no way to
 // load a class using the bootstrap ClassLoader that works
 // in both JDK 1.1 and Java 2.  However, this should still
 // work b/c the following should be true:
 //
 // (cl == null) iff current ClassLoader == null
 //
 // Thus Class.forName(String) will use the current
 // ClassLoader which will be the bootstrap ClassLoader.
 providerClass = Class.forName(className);
 } else {
 try {
 providerClass = cl.loadClass(className);
 } catch (ClassNotFoundException x) {
 if (doFallback) {
 // Fall back to current classloader
 ClassLoader current = 
 ObjectFactory.class.getClassLoader();
 if (current == null) {
 providerClass = Class.forName(className);
 } else if (cl != current) {
 cl = current;
 providerClass = cl.loadClass(className);
 } else {
 throw x;
 }
 } else {
 throw x;
 }
 }
 }
   */
 return providerClass;
 }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2589) ObjectFactory is reloading classes over-and-over causing performance issues with XPATH.


 [ 
https://issues.apache.org/jira/browse/XALANJ-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

brian yoder updated XALANJ-2589:


Attachment: ObjectFactory_orig.java

 ObjectFactory is reloading classes over-and-over causing performance issues 
 with XPATH.
 ---

 Key: XALANJ-2589
 URL: https://issues.apache.org/jira/browse/XALANJ-2589
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
Affects Versions: 2.7.2
 Environment: Glassfish 3.1 with JDK 1.6 u37
Reporter: brian yoder
Assignee: Steven J. Hathaway
 Attachments: ObjectFactory.java, ObjectFactory_orig.java


 I have done some performance benchmarking on XPath, and found that the 
 ObjectFactory kept calling findProviderClass, which has code that is calling 
 the following:
 providerClass = cl.loadClass(className);
 This is VERY inefficient, and is causing a severe bottleneck.  If i comment 
 this code out, and instead use the following I see a significant performance 
 improvement.
 Class providerClass = Class.forName(className);
 I am running on Glassfish 3.1 - and the bottlneck is really bad because my 
 JAR files were on SAN, so this code is running very slow.
 // Here is the code which I commented out, and rely ONLY on the Class.forName 
 method.  Not sure why the other stuff is needed, maybe only to support older 
 JVM's?
 /**
  * Find a Class using the specified ClassLoader
  */ 
 static Class findProviderClass(String className, ClassLoader cl,
boolean doFallback)
 throws ClassNotFoundException, ConfigurationError
 {   
 //throw security exception if the calling thread is not allowed to 
 access the
 //class. Restrict the access to the package classes as specified in 
 java.security policy.
 SecurityManager security = System.getSecurityManager();
 try{
 if (security != null){
 final int lastDot = className.lastIndexOf('.');
 String packageName = className;
 if (lastDot != -1) packageName = className.substring(0, 
 lastDot);
 security.checkPackageAccess(packageName);
  }   
 }catch(SecurityException e){
 throw e;
 }

 Class providerClass = Class.forName(className);
 /*
 if (cl == null) {
 // XXX Use the bootstrap ClassLoader.  There is no way to
 // load a class using the bootstrap ClassLoader that works
 // in both JDK 1.1 and Java 2.  However, this should still
 // work b/c the following should be true:
 //
 // (cl == null) iff current ClassLoader == null
 //
 // Thus Class.forName(String) will use the current
 // ClassLoader which will be the bootstrap ClassLoader.
 providerClass = Class.forName(className);
 } else {
 try {
 providerClass = cl.loadClass(className);
 } catch (ClassNotFoundException x) {
 if (doFallback) {
 // Fall back to current classloader
 ClassLoader current = 
 ObjectFactory.class.getClassLoader();
 if (current == null) {
 providerClass = Class.forName(className);
 } else if (cl != current) {
 cl = current;
 providerClass = cl.loadClass(className);
 } else {
 throw x;
 }
 } else {
 throw x;
 }
 }
 }
   */
 return providerClass;
 }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANJ-2493) BasisLibrary.nodeList2Iterator broken

[
https://issues.apache.org/jira/browse/XALANJ-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096876#comment-14096876
]

Uwe Schindler commented on XALANJ-2493:
---

(6 is the last node in the Node-Set, the empty text node)

I fixed the issue by calling normalize() before returning the NodeList as quick
hack. Later I did a better fix to not create the empty nodes at all.

In XALAN 2.7.1 this worked without any problem.

Should I open a new issue for that?

BasisLibrary.nodeList2Iterator broken
-

Key: XALANJ-2493
URL: https://issues.apache.org/jira/browse/XALANJ-2493
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone(Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: XSLTC
Affects Versions: 2.7.1
Reporter: Martin von Gagern
Fix For: The Latest Development Code, 2.7.2

Attachments: XALANJ-2493_1.patch, XALANJ-2493_2.patch,
XALANJ_2493_Test1.java

The current implementation of nodeList2Iterator is broken, because it can not
deal with attribute nodes. It relies on copyNodes which in turn tries to add
attribute nodes as children of some top level node. Attributes don't live on
the children axis, though, so this is against DOM and causes a DOM exception
in the Xerces DOM implementation and probably most other implementations. The
resulting HIERARCHY_REQUEST_ERR was noted e.g. in XALANJ-2424.
Furthermore, the implementation is inefficient, because it manually copies
each and every node from the source document to a new DTM to some new DTM.
The time overhead for the copying as well as the memory overhead for the
additional DOM can be avoided in cases where the nodes come from some input
document, as opposed to a document completely loaded within some extension
function.
A comment in the related XALANJ-2425 suggests returning DTMIterator from
extension functions and avoiding the re-import for those. I don't like this
idea because it exposes a lot of Xalans internals to extension functions, and
because the returned node list might be newly created, while at least some of
thenodes might still be from the same document. So instead of special cases
for the list type, I implemented special cases for every node of the list. If
it is a proxy node of the same (Multi)DOM, we simply use its handle.
If not, we add it to some w3c DOM and turn that into a DTM, pretty much like
the current implementation does. However, I dropped copyNodes in favor of
Document.importNode, to avoid code duplication and rely on supposedly more
heavily tested code. I also added another level of elements, so that there is
one such dummy node for every item of the source list, with always a single
child or element. A few assertions help ensure this single child policy. This
is especially important in the new implementation, because otherwise it would
become difficult to get the proxied nodes and the newly DTMified nodes into
correct order.
Right now, the import of DOM nodes is only implemented for those nodes I
expect to turn up in the DTM in pretty much the same form as they do in the
w3c DOM. For all other nodes, an internal error is thrown. This especially
concerns document fragment nodes. At least in w3c DOM, a document fragment
can never be a child, so if DTM behaves the same, we would need to import
document fragments seperately, or expand them to the list of their children
instead. I'm not sure what correct behaviour would be here, so I'd rather
throw an exception than implement wrong behaviour.
I also noticed that
org.apache.xml.dtm.ref.DTMManagerDefault.getDTMHandleFromNode would in theory
provide an implementation for turning w3c nodes into DTM handles - exactly
what we need here. That method seems to start importing from the topmost
ancestor of a node, giving as much context as possible, in contrast to both
current and my suggested XSLTC approach, which destroys ancestor references.
That method also seems to employ caches in order to avoid importing a
document repeatedly. Sadly, actually using that method throws a
ClassCastException as it expects a DTM

[jira] [Commented] (XALANJ-2493) BasisLibrary.nodeList2Iterator broken

2014-08-14 Thread Gary Gregory (JIRA)

[
https://issues.apache.org/jira/browse/XALANJ-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096890#comment-14096890
]

Gary Gregory commented on XALANJ-2493:
--

Yes please create a new ticket with full details.

FYI:
The code is here:
https://svn.apache.org/repos/asf/xalan/java/branches/xalan-j_2_7_1_maint
The tests are here:
https://svn.apache.org/repos/asf/xalan/test/branches/xalan-j_2_7_x

Thank you!

Gary

BasisLibrary.nodeList2Iterator broken
-

Attachments: XALANJ-2493_1.patch, XALANJ-2493_2.patch,
XALANJ_2493_Test1.java

[jira] [Commented] (XALANJ-2590) InternalRuntimeError: Expected element missing at 6 after upgrade to XALAN 2.7.2


[ 
https://issues.apache.org/jira/browse/XALANJ-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096903#comment-14096903
 ] 

Uwe Schindler commented on XALANJ-2590:
---

This seems to be caused by XALANJ-2590: The DOM NodeList gets copied to a DTM. 
During this process, it looks like empty text nodes are removed. This causes a 
problem at the end of the iteration. The new Exception was added in this commit.

I will try to produce a testcase with a extension function that creates a 
DocumentFragment with some empty text nodes, which returns 
DocFrag.getChildNodes(), so a nodelist with some empty text nodes.

 InternalRuntimeError: Expected element missing at 6 after upgrade to XALAN 
 2.7.2
 --

 Key: XALANJ-2590
 URL: https://issues.apache.org/jira/browse/XALANJ-2590
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
  Components: DTM, Xalan
Affects Versions: 2.7.2
Reporter: Uwe Schindler
Assignee: Steven J. Hathaway

 Hi,
 after upgrading to XALAN 2.7.2, I got very strange errors in one of my XSL 
 transformations, but just for some documents. It took a while to find the 
 problem:
 I have an extension function that returns a NodeList with some elements and 
 text nodes (some HTML). Unfortunately this NodeList contained an *empty* text 
 node as very last element. This is perfectly fine for DOM, because there is 
 nothing that forbids empty text nodes. This empty node caused the following 
 error when invoking xsl:copy-of select=java:Class:myExtensionFunction()/:
 {{InternalRuntimeError: Expected element missing at 6}}
 (6 is the last node in the Node-Set, the empty text node)
 I fixed the issue by calling normalize() before returning the NodeList as 
 quick hack. Later I did a better fix to not create the empty nodes at all.
 In XALAN 2.7.1 this worked without any problem.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANJ-2590) InternalRuntimeError: Expected element missing at 6 after upgrade to XALAN 2.7.2

[
https://issues.apache.org/jira/browse/XALANJ-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Uwe Schindler updated XALANJ-2590:
--

Component/s: (was: Xalan)
XSLTC

InternalRuntimeError: Expected element missing at 6 after upgrade to XALAN
2.7.2
--

Key: XALANJ-2590
URL: https://issues.apache.org/jira/browse/XALANJ-2590
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone(Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: DTM, XSLTC
Affects Versions: 2.7.2
Reporter: Uwe Schindler
Assignee: Steven J. Hathaway

Hi,
after upgrading to XALAN 2.7.2, I got very strange errors in one of my XSL
transformations, but just for some documents. It took a while to find the
problem:
I have an extension function that returns a NodeList with some elements and
text nodes (some HTML). Unfortunately this NodeList contained an *empty* text
node as very last element. This is perfectly fine for DOM, because there is
nothing that forbids empty text nodes. This empty node caused the following
error when invoking xsl:copy-of select=java:Class:myExtensionFunction()/:
{{InternalRuntimeError: Expected element missing at 6}}
(6 is the last node in the Node-Set, the empty text node)
I fixed the issue by calling normalize() before returning the NodeList as
quick hack. Later I did a better fix to not create the empty nodes at all.
In XALAN 2.7.1 this worked without any problem.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Comment Edited] (XALANJ-2590) InternalRuntimeError: Expected element missing at 6 after upgrade to XALAN 2.7.2


[ 
https://issues.apache.org/jira/browse/XALANJ-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14096903#comment-14096903
 ] 

Uwe Schindler edited comment on XALANJ-2590 at 8/14/14 12:17 PM:
-

This seems to be caused by XALANJ-2493: The DOM NodeList gets copied to a DTM. 
During this process, it looks like empty text nodes are removed. This causes a 
problem at the end of the iteration. The new Exception was added in this commit.

I will try to produce a testcase with a extension function that creates a 
DocumentFragment with some empty text nodes, which returns 
DocFrag.getChildNodes(), so a nodelist with some empty text nodes.


was (Author: thetaphi):
This seems to be caused by XALANJ-2590: The DOM NodeList gets copied to a DTM. 
During this process, it looks like empty text nodes are removed. This causes a 
problem at the end of the iteration. The new Exception was added in this commit.

I will try to produce a testcase with a extension function that creates a 
DocumentFragment with some empty text nodes, which returns 
DocFrag.getChildNodes(), so a nodelist with some empty text nodes.

 InternalRuntimeError: Expected element missing at 6 after upgrade to XALAN 
 2.7.2
 --

 Key: XALANJ-2590
 URL: https://issues.apache.org/jira/browse/XALANJ-2590
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone(Ordinary problems in 
 Xalan projects.  Anybody can view the issue.) 
  Components: DTM, XSLTC
Affects Versions: 2.7.2
Reporter: Uwe Schindler
Assignee: Steven J. Hathaway

 Hi,
 after upgrading to XALAN 2.7.2, I got very strange errors in one of my XSL 
 transformations, but just for some documents. It took a while to find the 
 problem:
 I have an extension function that returns a NodeList with some elements and 
 text nodes (some HTML). Unfortunately this NodeList contained an *empty* text 
 node as very last element. This is perfectly fine for DOM, because there is 
 nothing that forbids empty text nodes. This empty node caused the following 
 error when invoking xsl:copy-of select=java:Class:myExtensionFunction()/:
 {{InternalRuntimeError: Expected element missing at 6}}
 (6 is the last node in the Node-Set, the empty text node)
 I fixed the issue by calling normalize() before returning the NodeList as 
 quick hack. Later I did a better fix to not create the empty nodes at all.
 In XALAN 2.7.1 this worked without any problem.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2592) Support for XSLT 2

2014-08-29 Thread Nicolas Debeissat (JIRA)

Nicolas Debeissat created XALANJ-2592:
-

 Summary: Support for XSLT 2
 Key: XALANJ-2592
 URL: https://issues.apache.org/jira/browse/XALANJ-2592
 Project: XalanJ2
  Issue Type: Improvement
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Xalan
Affects Versions: 2.7.2
Reporter: Nicolas Debeissat
Assignee: Steven J. Hathaway


What about supporting XSLT 2 ?




--
This message was sent by Atlassian JIRA
(v6.2#6252)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2593) Incorrect showing of supplementary characters in attributes

2014-09-09 Thread Eugene Shkel (JIRA)

Eugene Shkel created XALANJ-2593:


 Summary: Incorrect showing of supplementary characters in 
attributes
 Key: XALANJ-2593
 URL: https://issues.apache.org/jira/browse/XALANJ-2593
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Serialization
Affects Versions: 2.7.2
 Environment: Win 7 x64, Java 1.6 
Reporter: Eugene Shkel
Assignee: Steven J. Hathaway


In Xalan 2.7.2 the supplementary characters (see 
http://www.oracle.com/technetwork/articles/javase/supplementary-142654.html for 
details) shown incorrectly in attributes .
For example, I need to show symbols ㎴ ( # 144308 ; ) or ب ( # 132648 ; ) in 
attribute y of element x
Expected result: {code}?xml version=1.0 encoding=UTF-8?x y=#144308; - 
#132648;/{code}
Actual result for Xalan 2.7.2 is:{code} ?xml version=1.0 
encoding=UTF-8?x y=#55372;#57268; - #55361;#56872;/{code}

Code snippet for test:
{code}
public static void main(String[] argv) throws Exception {
TransformerFactory tFactory = TransformerFactory.newInstance();
StreamSource stylesource = new StreamSource(new StringReader(?xml 
version=\1.0\ encoding=\UTF-8\?xsl:stylesheet 
xmlns:xsl=\http://www.w3.org/1999/XSL/Transform\; version=\1.0\ 
xsl:template match=\/\x y=\{xslt/search/value1}\ 
//xsl:template/xsl:stylesheet));
Transformer transformer = tFactory.newTransformer(stylesource);
StreamSource source = new StreamSource(new StringReader(?xml 
version=\1.0\?xsltsearchvalue1㎴ - ب/value1/search/xslt));
Result result = new StreamResult(System.out);
transformer.transform(source, result);
} 
{code}
The problem relates to the method 
org.apache.xml.serializer.ToStream.writeAttrString(Writer, String, String). 
{code}
if (m_charInfo.shouldMapAttrChar(ch)) {
// The character is supposed to be replaced by a String
// e.g.   ''  --  amp;
// e.g.   ''  --  lt;
accumDefaultEscape(writer, ch, i, stringChars, len, false, 
true);
}
{code}
this part doesn't process multicharacter sequences like supplementary 
characters within Java platform and this leads to executing next part within 
same method
{code}
else {
// This is a fallback plan, we should never get here
// but if the character wasn't previously handled
// (i.e. isn't in the encoding, etc.) then what
// should we do?  We choose to write out a character ref
writer.write(!13#);
writer.write(Integer.toString(ch));
writer.write(';');
}
{code}
 PS: Can't add patch file, so put here.
{code}
--- src\org\apache\xml\serializer\ToStream.java 2014-03-26 17:21:30 +0200
+++ src\org\apache\xml\serializer\ToStream.java 2014-09-09 19:09:30 +0300
@@ -2112,8 +2112,13 @@
 // e.g.   ''  --  amp;
 // e.g.   ''  --  lt;
 accumDefaultEscape(writer, ch, i, stringChars, len, false, 
true);
-}
-else {
+} else if (Encodings.isHighUTF16Surrogate(ch)) {
+// more than single input character can be processed
+// within accumDefaultEscape()
+// so we set appropriate value for loop for().
+i = accumDefaultEscape(writer, ch, i, stringChars, len, false, 
true); 
+
+} else {
 if (0x0 = ch  ch = 0x1F) {
 // Range 0x00 through 0x1F inclusive
 // This covers the non-whitespace control characters
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANC-757) Makefile does not honor CPPFLAGS

2014-10-20 Thread Bill Blough (JIRA)


 [ 
https://issues.apache.org/jira/browse/XALANC-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Blough updated XALANC-757:
---
Attachment: honor_cppflags.diff

 Makefile does not honor CPPFLAGS
 

 Key: XALANC-757
 URL: https://issues.apache.org/jira/browse/XALANC-757
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
Reporter: Bill Blough
Assignee: Steven J. Hathaway
Priority: Minor
 Attachments: honor_cppflags.diff


 While the makefiles honor passed-in CXXFLAGS and LDFLAGS, they do not honor 
 passed-in CPPFLAGS.
 Patch attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-758) TraceListenerDefault.cpp:336: bad expression

2015-01-15 Thread David Binderman (JIRA)

David Binderman created XALANC-758:
--

 Summary: TraceListenerDefault.cpp:336: bad expression
 Key: XALANC-758
 URL: https://issues.apache.org/jira/browse/XALANC-758
 Project: XalanC
  Issue Type: Bug
Affects Versions: 1.11
Reporter: David Binderman
Assignee: Steven J. Hathaway
Priority: Minor


xalan-c-1.11/c/src/xalanc/XSLT/TraceListenerDefault.cpp:336]: (style) Same 
expression in both branches of ternary operator.

const NodeRefListBase  theNodeSet =
m_executionContext != 0 ?
ev.m_selection-nodeset() :
ev.m_selection-nodeset();




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANJ-2594) Incorrect exception being thrown

2015-03-15 Thread Devin Chollak (JIRA)

Devin Chollak created XALANJ-2594:
-

 Summary: Incorrect exception being thrown
 Key: XALANJ-2594
 URL: https://issues.apache.org/jira/browse/XALANJ-2594
 Project: XalanJ2
  Issue Type: Bug
  Security Level: No security risk; visible to anyone (Ordinary problems in 
Xalan projects.  Anybody can view the issue.)
  Components: Xalan
Affects Versions: 2.7.2
Reporter: Devin Chollak
Assignee: Steven J. Hathaway
Priority: Minor


Using an automated research tool I detected in 
src\org\apache\xpath\domapi\XPathResultImpl.java on lines 111 to 113 you throw 
an XPathException; however, the expectation is for it to be either a 
NullPointerException or RuntimeException instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Comment Edited] (XALANJ-2195) Memory leak in XMLReaderManager

2015-03-13 Thread Srdan Srepfler (JIRA)


[ 
https://issues.apache.org/jira/browse/XALANJ-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14360257#comment-14360257
 ] 

Srdan Srepfler edited comment on XALANJ-2195 at 3/13/15 12:12 PM:
--

Can this be triggered by a SAXParseException as well? I see 2.7.2 is the latest 
Xalan, any chance it solved this issue?
example: {code}org.xml.sax.SAXParseException: An invalid XML character 
(Unicode: 0x{2}) was found in the value of attribute {1} and element is 
1d.{code}




was (Author: schrepfler):
Can this be triggered by a SAXParseException as well? I see 2.7.2 is the latest 
Xalan, any chance it solved this issue?
example: org.xml.sax.SAXParseException: An invalid XML character (Unicode: 
0x{2}) was found in the value of attribute {1} and element is 1d.



 Memory leak in XMLReaderManager
 ---

 Key: XALANJ-2195
 URL: https://issues.apache.org/jira/browse/XALANJ-2195
 Project: XalanJ2
  Issue Type: Bug
  Components: Xalan
Affects Versions: 2.7
Reporter: Marko Strukelj
Priority: Blocker
 Attachments: gc-roots.jpg, retained-object-sizes.jpg, 
 xalan-j2-2.6.0-xmlmemoryleak-tm2l.patch


 In class org.apache.xml.utils.XMLReaderManager 
 getXMLReader() method creates a new XMLReader (i.e. SAXParser) and stores it 
 into ThreadLocal.
 releaseXMLReader() does not remove (set to null) ThreadLocal thus creating a 
 permanent leak.
 Unfortunately the size of the cached Reader is typically dependent upon the 
 size of the XML document you process (depends on implementation but this is 
 the case with xerces SAXParser). In heavy load server environments with 
 thread pools of tens and hundreds of threads the server sustains a 
 significant memory leak (hundreds of megabytes - depending on the XML 
 document sizes and number of threads in a thread pools).
 A fix is trivial:
 Put the following line at the end of releaseXMLReader method:
 m_readers.set(null);
 I wonder, why is reader stored in ThreadLocal in the first place?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-759) Performance issue in XalanTransformer.transform()

2015-02-27 Thread Radhika MG (JIRA)

Radhika MG created XALANC-759:
-

 Summary: Performance issue in XalanTransformer.transform()
 Key: XALANC-759
 URL: https://issues.apache.org/jira/browse/XALANC-759
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.10
 Environment: Windows
Reporter: Radhika MG
Assignee: Steven J. Hathaway
Priority: Critical


We use Xalan 1.10 and Xerces 2.7 in our code built in C++ on Windows OS. 
One of our customers who upgraded from previous version of our product to the 
latest in suite is facing performance issue in Xalan transform. 
Between two versions of our product, the Xalan and Xerces have been upgraded. 
We tried to compare the time taken for transform with respective versions of 
Xalan that we used in our products, for the same xml and style sheets. The 
result is as below: 

With Xalan 1.6 and Xerces 2.3
Xalan -t -o pdp.out Calendar.xml ConvertCalendarsToPdp_1.xsl
Source tree parsing time: 668.791 milliseconds.
Stylesheet compilation time: 89.449 milliseconds.
Transformation time: 324617.921 milliseconds. (5.41 minutes)

With Xalan 1.10 and Xerces 2.7 
Xalan -t -o pdp.out Calendar.xml ConvertCalendarsToPdp_1.xsl
Source tree parsing time: 71.238 milliseconds.
Stylesheet compilation time: 14.367 milliseconds.
Transformation time: 3477100.2128 milliseconds. (57.95 minutes)

Please suggest how we could improve the transform time. Does it require code 
change at our end? 
Please let us know. 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANC-762) Stack is corrupted in DOMStringHelper::NumberToCharacters() if value is really big

2015-04-03 Thread Sergey Kurenkov (JIRA)


 [ 
https://issues.apache.org/jira/browse/XALANC-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Kurenkov updated XALANC-762:
---
Description: 
in functions 
void
DOMStringHelper::NumberToCharacters(
double  theValue,
FormatterListener  formatterListener,
MemberFunctionPtr   function)

and 

NumberToDOMString(
double  theValue,
XalanDOMString theResult)

an array is created on stack in order to convert theValue:
chartheBuffer[MAX_PRINTF_DIGITS + 1];

If theValue is quite big for example 1.79769e+308 which is the biggest possible 
double value than theBuffer is overritten since it just allocates only 100 
bytes for storing theValue whereas when this format string is used %.35f it 
requires around 350 bytes to store the converted double.


I think, first MAX_PRINTF_DIGITS is used by mistake in this context. Instead 
MAX_FLOAT_CHARACTERS should have been used. And MAX_FLOAT_CHARACTERS must be 
defined like this:

// The maximum number of characters for a floating point number.

 const size_tMAX_FLOAT_CHARACTERS = 400;

in order to have enough space to store 308 digits before the point, a point and 
up to 35 digits after the point and the NULL terminator at the end



  was:
in functions 
void
DOMStringHelper::NumberToCharacters(
double  theValue,
FormatterListener  formatterListener,
MemberFunctionPtr   function)

and 

NumberToDOMString(
double  theValue,
XalanDOMString theResult)

an array is created on stack in order to convert theValue:
chartheBuffer[MAX_PRINTF_DIGITS + 1];

If theValue is quite big for example 1.79769e+308 which is the biggest possible 
double value than theBuffer is overritten since it just allocates only 100 
bytes for storing theValue whereas when this format string is used %.35f it 
requires around 350 bytes to store the converted double.



 Stack is corrupted in DOMStringHelper::NumberToCharacters() if value is 
 really big
 --

 Key: XALANC-762
 URL: https://issues.apache.org/jira/browse/XALANC-762
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
Reporter: Sergey Kurenkov
Assignee: Steven J. Hathaway
Priority: Minor

 in functions 
 void
 DOMStringHelper::NumberToCharacters(
 double  theValue,
 FormatterListener  formatterListener,
 MemberFunctionPtr   function)
 and 
 NumberToDOMString(
 double  theValue,
 XalanDOMString theResult)
 an array is created on stack in order to convert theValue:
 chartheBuffer[MAX_PRINTF_DIGITS + 1];
 If theValue is quite big for example 1.79769e+308 which is the biggest 
 possible double value than theBuffer is overritten since it just allocates 
 only 100 bytes for storing theValue whereas when this format string is used 
 %.35f it requires around 350 bytes to store the converted double.
 I think, first MAX_PRINTF_DIGITS is used by mistake in this context. Instead 
 MAX_FLOAT_CHARACTERS should have been used. And MAX_FLOAT_CHARACTERS must be 
 defined like this:
 // The maximum number of characters for a floating point number.  
   
  const size_tMAX_FLOAT_CHARACTERS = 400;
 in order to have enough space to store 308 digits before the point, a point 
 and up to 35 digits after the point and the NULL terminator at the end



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-762) Stack is corrupted in DOMStringHelper::NumberToCharacters() if value is really big

2015-04-03 Thread Sergey Kurenkov (JIRA)

Sergey Kurenkov created XALANC-762:
--

 Summary: Stack is corrupted in 
DOMStringHelper::NumberToCharacters() if value is really big
 Key: XALANC-762
 URL: https://issues.apache.org/jira/browse/XALANC-762
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
Reporter: Sergey Kurenkov
Assignee: Steven J. Hathaway
Priority: Minor


in functions 
void
DOMStringHelper::NumberToCharacters(
double  theValue,
FormatterListener  formatterListener,
MemberFunctionPtr   function)

and 

NumberToDOMString(
double  theValue,
XalanDOMString theResult)

an array is created on stack in order to convert theValue:
chartheBuffer[MAX_PRINTF_DIGITS + 1];

If theValue is quite big for example 1.79769e+308 which is the biggest possible 
double value than theBuffer is overritten since it just allocates only 100 
bytes for storing theValue whereas when this format string is used %.35f it 
requires around 350 bytes to store the converted double.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-763) Integrate XalanC builds with XercesC - Create upgrade path to Microsoft Visual Studio 2013.

Steven J. Hathaway created XALANC-763:
-

 Summary: Integrate XalanC builds with XercesC - Create upgrade 
path to Microsoft Visual Studio 2013.
 Key: XALANC-763
 URL: https://issues.apache.org/jira/browse/XALANC-763
 Project: XalanC
  Issue Type: Task
Reporter: Steven J. Hathaway
Assignee: Steven J. Hathaway
Priority: Minor
 Fix For: CurrentCVS






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Created] (XALANC-764) $issue.summary

Steven J. Hathaway created XALANC-764:
-

 Summary: $issue.summary
 Key: XALANC-764
 URL: https://issues.apache.org/jira/browse/XALANC-764
 Project: XalanC
  Issue Type: Task
Reporter: Steven J. Hathaway
Assignee: Steven J. Hathaway
Priority: Blocker
 Fix For: CurrentCVS






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Commented] (XALANC-744) XalanLocator::getSystemId() can return NULL, cause crash


[ 
https://issues.apache.org/jira/browse/XALANC-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14530027#comment-14530027
 ] 

Steven J. Hathaway commented on XALANC-744:
---

Tom,
Thanks for your finding.  I will again review the code and commit - or define 
another fix.


 XalanLocator::getSystemId() can return NULL, cause crash
 

 Key: XALANC-744
 URL: https://issues.apache.org/jira/browse/XALANC-744
 Project: XalanC
  Issue Type: Bug
  Components: XalanC
Affects Versions: 1.11
 Environment: Windows, Visual Studio 2010
Reporter: Michael Chisholm
Assignee: Steven J. Hathaway
Priority: Critical

 I think this is a copy-paste bug, introduced in r1388736:
 Index: XalanLocator.hpp
 ===
 --- XalanLocator.hpp(revision 1388735)
 +++ XalanLocator.hpp(revision 1388736)
 @@ -67,17 +67,19 @@
  static const XalanDOMChar*
  getPublicId(
  const Locator*  theLocator,
 -const XalanDOMChar* theAlternateId = 0)
 +const XalanDOMChar* theAlternateId = s_dczero)
  {
 -return theLocator == 0 ? theAlternateId : theLocator-getPublicId();
 +return theLocator == 0 ? theAlternateId : (theLocator-getPublicId() 
 ?
 +theLocator-getPublicId() : theAlternateId);
  }
  static const XalanDOMChar*
  getSystemId(
  const Locator*  theLocator,
 -const XalanDOMChar* theAlternateId = 0)
 +const XalanDOMChar* theAlternateId = s_dczero)
  {
 -return theLocator == 0 ? theAlternateId : theLocator-getSystemId();
 +return theLocator == 0 ? theAlternateId : (theLocator-getSystemId() 
 ?
 +theLocator-getPublicId() : theAlternateId);
  }
  static XalanFileLoc
 @@ -122,6 +124,8 @@
  XalanLocator
  operator=(const XalanLocator);
 +
 +const static XalanDOMChar s_dczero = 0;
  };
 Notice that in the getSystemId() method, theLocator-getPublicId() is called. 
  I think that was meant to be theLocator-getSystemId().  This caused a crash 
 when I used Xalan.exe because it sets up its XSLTInputSources with system 
 Ids, but not public Ids.  Then, during transformation, 
 XalanLocator::getSystemId() is called, which returns the NULL public Id, 
 which is passed to the XalamDomString constructor, which causes the crash.
 I just switched the call to theLocator-getSystemId() and the crash 
 disappeared.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

[jira] [Updated] (XALANC-763) Integrate XalanC builds with XercesC - Create upgrade path to Microsoft Visual Studio 2013.