[ https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783833#action_12783833
]
Adam Jenkins commented on XALANJ-2510:
--------------------------------------
Hi Henry,
Yep, you're correct re xsl:param and xsl:variable. I didn't really consider xsl:with-param
or func:result, as I guessed that if people want to do that, they can just create a variable
first and pass that to the with-param. I only chose to modify ElemVariable so as to keep
my impact on Xalan base minimal.
As for a sample, it depends on the use case and there are a lot of use cases :)
Usually I first test the parent thus:
protected boolean setVariableIfPossible(Object variable, ElemExtensionCall thisElement){
if(thisElement.getParentElem() instanceof ElemVariable){
ElemVariable varElement = (ElemVariable)thisElement.getParentElem();
varElement.overrideChildDocument(new XPath(new XObject(variable)));
return true;
}
return false;
}
if this returns false, the action is different for each extension element. For instance,
I have an element that configures a JPA entity manager that is used thus:
<xsl:variable name="entityManager">
<jpa:entityManager persistenceUnit="myPU">
<jpa:property name="flush" value="true"/>
</ejb:entityManager>
</xsl:variable>
Now, if that isn't inside a variable element, it sets up a default entityManager for the entire
transformation. However, I have another JPA element called query that is used thus:
<xsl:variable name="customers">
<jpa:query name="customer/name" location="customer/address/city" type="customer/@type">
from Customer c where c.name = :name and c.city = :location and c.customerType
= :type
<jpa:query>
<xsl:variable>
where the attributes of the extension element are mapped to the named parameters of the JPA
query. Now if this element isn't inside a <xsl:variable> element, then the response
is output as per standard:
context.outputToResultTree(context.getStylesheet(), queryResults);
I hope those two above give you a bit more of an idea of some of the stuff I'm doing. The
entire collection of extension elements/functions is open source at sxe.dev.java.net (though
I think it's still going throug approval, so you might have to log in to see it, or ask me
for permissions or something, I don't know how it works for pre-approved projects...let me
know)....I know the code in there isn't the best, so be kind ;). Also, I know some of the
stuff that those extensions allow you to do may not be considered best practice, however sometimes
they come in handy :)
In terms of the dynamic scope question, the answer should be addressed above, each of my extension
element has a different strategy for when it's not inside a xsl:variable element, and it's
up to the users of the library to read the doco and understand the impact on their transformations.
In regards to using an XPath...may not be the best solution, I just tried to keep things as
similar to how Xalan was currently doing things as possible so as to minimize my impact on
the project :). One of my primary motivations while thinking about how to impliment this
was how to keep the impact on Xalan to an absolute minimum, so I chose the shortest path to
accomplish my goal :)
I hope the above helps understand the motivation for this change a little more. Feel free
to checkout sxe.dev.java.net. I know some of the things it does are considered not exactly
best practice (for example, being able to send an email from an XSLT or being able to write
to a graph to a parallel binary stream), however it's an optional library, so I expect users
of it to understand the pros and cons of breaking some of the XSLT best practices.
I'll submit the license agreement you posted a link to sometime today (for some reason, my
ISP blocks apache, so I have to wait until I get to work :) ).
> Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)
> -------------------------------------------------------------------------------------
>
> Key: XALANJ-2510
> URL: https://issues.apache.org/jira/browse/XALANJ-2510
> 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-extensions
> Affects Versions: The Latest Development Code
> Reporter: Adam Jenkins
> Fix For: The Latest Development Code
>
> Attachments: XALANJ-2510.patch
>
>
> When using extension elements, there is no way to set a non XRTreeFrag related variable.
> For example, say you have:
> <xsl:variable name="myvar">
> <my:extension someAttribute="somevalue"/>
> </xsl:variable>
> If my:extension wants to set a tree fragment, string or nodeset into myvar, that's not
a problem, however if it wants to set a java object, currently there is no mechanism for that
(any java object passed either returned from the method or passed to XSLProcessorContext.outputToResultTree
is toString()'ed before being passed back to the ElemVariable.getValue() method).
> The proposed change (patch supplied) is to supply an optional variable on ElemVariable.java
whereby child extension elements can call up to their parent and set an XPath to be evaluated
after the extension element has finished processing.
> This requires only very minor modification to the ElemVariable.getValue method to check
this variable.
> This also ensures that this is optional functionality and will not affect that basic
Xalan processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783695#action_12783695
]
Henry Zongaro commented on XALANJ-2510:
---------------------------------------
Hi, Adam.
Thank you for the contribution.
I've taken a quick look at your patch. One thing I notice immediately is that it applies
to xsl:param and xsl:variable, but I expect you would want it to apply to xsl:with-param as
well - right? And probably the EXSLT func:result element, too.
I'd also like to understand how this interacts with other features of the language. Without
a sample implementation of an extension element like the one you've posited, it's difficult
to tell whether this new feature is well-integrated.
For instance, suppose I make the extension element in the content of an xsl:if or xsl:choose
to evaluate it conditionally, will that work?
<xsl:variable name="myvar">
<xsl:if test="condition">
<my:extension someAttribute="somevalue"/>
</xsl:if>
</xsl:variable>
The way you've written the patch, it looks like you're expecting this kind of element that
needs to return an "override" value to be a child of an xsl:variable/xsl:param. Similarly,
what if the extension element is in the dynamic scope of an xsl:variable rather than the static
scope - i.e., what if the xsl:variable contains an xsl:call-template, and that named template
contains the extension element. How does the override get set on the xsl:variable that contained
the call? Again, a sample implementation of such an extension element might have helped to
clarify the way the mechanism works.
Finally, I wonder about the way the result is set on the xsl:variable is through this mechanism
of supplying an alternative XPath expressions, rather than somehow integrating it as a different
result kind.
By the way, it's important that any contribution that's not completely trivial be covered
by a contributor's license agreement. That assures the ASF that you have the right to make
the contribution. May I suggest that you submit one? You can find it here.[1]
[1] http://www.apache.org/licenses/#clas
> Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)
> -------------------------------------------------------------------------------------
>
> Key: XALANJ-2510
> URL: https://issues.apache.org/jira/browse/XALANJ-2510
> 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-extensions
> Affects Versions: The Latest Development Code
> Reporter: Adam Jenkins
> Fix For: The Latest Development Code
>
> Attachments: XALANJ-2510.patch
>
>
> When using extension elements, there is no way to set a non XRTreeFrag related variable.
> For example, say you have:
> <xsl:variable name="myvar">
> <my:extension someAttribute="somevalue"/>
> </xsl:variable>
> If my:extension wants to set a tree fragment, string or nodeset into myvar, that's not
a problem, however if it wants to set a java object, currently there is no mechanism for that
(any java object passed either returned from the method or passed to XSLProcessorContext.outputToResultTree
is toString()'ed before being passed back to the ElemVariable.getValue() method).
> The proposed change (patch supplied) is to supply an optional variable on ElemVariable.java
whereby child extension elements can call up to their parent and set an XPath to be evaluated
after the extension element has finished processing.
> This requires only very minor modification to the ElemVariable.getValue method to check
this variable.
> This also ensures that this is optional functionality and will not affect that basic
Xalan processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783208#action_12783208
]
Adam Jenkins commented on XALANJ-2510:
--------------------------------------
Just a quick check to see where this is at...did you require any further information from
me Henry? We're hoping to release our open source extension element/function library the
end of next week on dev.java.net, just wondering whether this is likely to be in by then?
Cheers
Adam
> Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)
> -------------------------------------------------------------------------------------
>
> Key: XALANJ-2510
> URL: https://issues.apache.org/jira/browse/XALANJ-2510
> 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-extensions
> Affects Versions: The Latest Development Code
> Reporter: Adam Jenkins
> Fix For: The Latest Development Code
>
> Attachments: XALANJ-2510.patch
>
>
> When using extension elements, there is no way to set a non XRTreeFrag related variable.
> For example, say you have:
> <xsl:variable name="myvar">
> <my:extension someAttribute="somevalue"/>
> </xsl:variable>
> If my:extension wants to set a tree fragment, string or nodeset into myvar, that's not
a problem, however if it wants to set a java object, currently there is no mechanism for that
(any java object passed either returned from the method or passed to XSLProcessorContext.outputToResultTree
is toString()'ed before being passed back to the ElemVariable.getValue() method).
> The proposed change (patch supplied) is to supply an optional variable on ElemVariable.java
whereby child extension elements can call up to their parent and set an XPath to be evaluated
after the extension element has finished processing.
> This requires only very minor modification to the ElemVariable.getValue method to check
this variable.
> This also ensures that this is optional functionality and will not affect that basic
Xalan processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Zongaro resolved XALANJ-2495.
-----------------------------------
Resolution: Fixed
Fix Version/s: The Latest Development Code
Applied Martin's patch to the main trunk of the source code repository.
> Corrections to German error messages
> ------------------------------------
>
> Key: XALANJ-2495
> URL: https://issues.apache.org/jira/browse/XALANJ-2495
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in Xalan projects.
Anybody can view the issue.)
> Components: Diagnostic-messages-resources
> Affects Versions: The Latest Development Code
> Reporter: Martin von Gagern
> Priority: Trivial
> Fix For: The Latest Development Code
>
> Attachments: Translation_de.patch
>
>
> I've noticed two translation errors in the German XSLTErrorResources. I'll attach a patch
for these. I haven't done a systematic check of translations, and don't know if I ever will,
but two fixed messages are better than none imho.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782849#action_12782849
]
Henry Zongaro commented on XALANJ-2490:
---------------------------------------
Hi, Martin.
Much of the documentation was originally written with the Xalan-J interpreter in mind. XSLTC-specific
limitations and differences are described on pages that are specific to XSLTC. In particular,
if you check the list at [1] you'll see that XSLTC does not support the xalan:component and
xalan:script elements.
Of course, it would be nice if the XSLTC documentation was better integrated into the main
Xalan-J documentation, so that differences could be called out in context.
We can either resolve this issue by returning it as "working as designed," or by changing
it to an enhancement request. Which would you prefer?
[1] http://xml.apache.org/xalan-j/extensions_xsltc.html#constraints
> Class name derived from namespace URI, not xalan:script element
> ---------------------------------------------------------------
>
> Key: XALANJ-2490
> URL: https://issues.apache.org/jira/browse/XALANJ-2490
> 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-extensions
> Affects Versions: The Latest Development Code
> Reporter: Martin von Gagern
>
> When implementing extensions in Java, it seems that Xalan (as of SVN revision 752801)
uses the namespace url to derive the name of an implementing class, whereas the documentation
at http://xml.apache.org/xalan-j/extensions.html#setup-script indicates that the xalan:script
subelement of the xalan:component element would be used to bind a namespace to its implementation.
> Before investigating this further, and trying to come up with a fix, I'd like to know
which one you consider correct, which one reflects intended behaviour. Do you want to determine
class names automagically from its namespace, or do you want to honour the script element
when compiling a function call?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782744#action_12782744
]
Henry Zongaro commented on XALANJ-2473:
---------------------------------------
Hi, Martin. Your patch for this bug report looks correct. However, I would recommend trying
to delegate the implementation of getTextContent to the underlying DTM implementation instead
of doing a recursive walk that ultimately gets the string value of each text or CData section
node and concatenates them all together. If the DTMNodeProxy wraps a node from a SAX2DTM
instance, in particular, the implementation can take advantage of the FastStringBuffer that
stores the character content of the SAX2DTM implementation. (Take a look at SAX2DTM.getStringValue(int)
to understand how that might be much faster.)
> DTMNodeProxy.getTextContent() does not return text content of child nodes
> -------------------------------------------------------------------------
>
> Key: XALANJ-2473
> URL: https://issues.apache.org/jira/browse/XALANJ-2473
> 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
> Affects Versions: 2.7.1
> Environment: Java 1.5
> Reporter: Christian Schröder
> Attachments: XALANJ-2473-getTextContent.patch, XALANJ_2473_Test1.java
>
>
> If a java extension functions takes an org.w3c.dom.Node as an argument then it gets an
org.apache.xml.dtm.ref.DTMNodeProxy object.
> The "getTextContent" method of this object returns null if the node is an element node,
although according to the java 1.5 documentation, the "getTextContent" method should return
the "concatenation of the textContent attribute value of every child node".
> This is the implementation:
> public String getTextContent() throws DOMException {
> return getNodeValue(); // overriden in some subclasses
> }
> Of course, "getNodeValue" returns null if the node is an element node, but I think this
is not the way "getTextContent" should be implemented.
> The following code can be used to reproduce this error:
> XSLT:
> <xsl:value-of select="src:myFunction(foo)"/>
> XML:
> <foo>Some Text</foo>
> Java:
> public static String myFunction(org.w3c.dom.Node n) {
> String s = n.getTextContent();
> // s should be "Some Text", but is actually null.
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Zongaro resolved XALANJ-2424.
-----------------------------------
Resolution: Fixed
Fix Version/s: The Latest Development Code
Fixed under JIra XALANJ-2493.
> set:distinct() over attribute list breaks XSLTC throwing HIERARCHY_REQUEST_ERR
> ------------------------------------------------------------------------------
>
> Key: XALANJ-2424
> URL: https://issues.apache.org/jira/browse/XALANJ-2424
> Project: XalanJ2
> Issue Type: Bug
> Components: XSLTC
> Affects Versions: 2.7.1, 2.7
> Environment: Linux, Sun java 1.6
> Reporter: Илья Казначеев
> Fix For: The Latest Development Code
>
> Attachments: Process.jad, xml1.xml, xsl1.xsl
>
>
> If you do set:distinct over attribute list, XSLTC-compiled translet throws HIERARCHY_REQUEST_ERR
exception.
> Exception is localised to point where set:distinct is called, even if it is assigned
into a variable.
> Test case:
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:set="http://exslt.org/sets"
version="1.0">
> <xsl:output method="html" />
> <xsl:template match="/">
> <xsl:variable name="attrs" select="set:distinct(source/element/@attr)"
/>
> <html><body>
> <xsl:for-each select="$attrs">
> <xsl:value-of select="." />
> </xsl:for-each>
> </body></html>
> </xsl:template>
> </xsl:stylesheet>
> With xml
> <source>
> <element attr="val1" name="foobar" />
> <element attr="val2" name="bar" />
> <element attr="val2" name="baz" />
> <element attr="val3" name="baz" />
> </source>
> that will cause an Exception to be thrown when variable is assigned.
> My unedicated guess is that it tries to apply-templates over selected nodes into document
in place where set:distinct is computed. This happens, as I see for different partially-serialized
document, before variable's enclosing element is closed. I've disassembled the stylesheet
but didn't understand much from there, it goes like this:
> // 30 66:invokeinterface #110 <Method org.w3c.dom.NodeList DOM.makeNodeList(DTMAxisIterator)>
> // 31 71:invokestatic #116 <Method org.w3c.dom.NodeList ExsltSets.distinct(org.w3c.dom.NodeList)>
> // 32 74:aload_0
> // 33 75:aload_1
> // 34 76:invokestatic #122 <Method DTMAxisIterator BasisLibrary.nodeList2Iterator(org.w3c.dom.NodeList,
org.apache.xalan.xsltc.Translet, DOM)>
> // 35 79:new #126 <Class CachedNodeListIterator>
> // 36 82:dup_x1
> // 37 83:swap
> // 38 84:invokespecial #127 <Method void CachedNodeListIterator(DTMAxisIterator)>
> // 39 87:iload 4
> // 40 89:invokeinterface #41 <Method DTMAxisIterator DTMAxisIterator.setStartNode(int)>
> // 41 94:astore 9
> // 42 96:aload_3
> // 43 97:ldc1 #129 <String "html">
> // 44 99:dup2
> // 45 100:invokeinterface #14 <Method void SerializationHandler.startElement(String)>
> P.S. If said variable is located in prologue (not inside any xsl:template) the bug persists.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henry Zongaro resolved XALANJ-2493.
-----------------------------------
Resolution: Fixed
Fix Version/s: The Latest Development Code
I have reviewed and applied Martin's second patch for this bug report.
> 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: The Latest Development Code
> Reporter: Martin von Gagern
> Fix For: The Latest Development Code
>
> 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 generate from a DOM source to be a DOM2DTM, which SAXImpl is not. A comment
inside that method also indicates that future implementations might drop auto-importing and
instead leave it to the caller to import a DOM if it hasn't been imported before.
> I left my own attempt at an nodeList2Iterator implementation using getDTMHandleFromNode
in place, renamed to nodeList2IteratorUsingHandleFromNode and made private. So it's there,
it even gets compiled, but it won't get used. If that method gets fixed in XSLTCDTMManager
or its ancestor, then this method might be used instead, giving a much simpler and cleaner
implementation. If some of my code would be useful for such an implementation as well, like
the check for "is same DOM", feel free to copy or move my code to those classes as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782460#action_12782460
]
Henry Zongaro commented on XALANJ-2493:
---------------------------------------
Right. I've always done my Xalan-J builds and test runs using JDK 1.3.x, to ensure I don't
let any 1.4 or later features creep in.
There's an InternalError class in the org.apache.xalan.xsltc.compiler.util package that's
intended to be used for situations where the compiler has found itself in some internally
inconsistent state. Traditionally we've avoided introducing dependencies on the compiler
packages in the XSLTC run-time packages - just to allow for the possibility of building a
smaller XSLTC run-time, though that hasn't been done recently. So I would suggest introducing
an InternalRuntimeError class in org.apache.xalan.xsltc.runtime instead of using AssertionError.
> 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: The Latest Development Code
> Reporter: Martin von Gagern
> Attachments: XALANJ-2493_1.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 generate from a DOM source to be a DOM2DTM, which SAXImpl is not. A comment
inside that method also indicates that future implementations might drop auto-importing and
instead leave it to the caller to import a DOM if it hasn't been imported before.
> I left my own attempt at an nodeList2Iterator implementation using getDTMHandleFromNode
in place, renamed to nodeList2IteratorUsingHandleFromNode and made private. So it's there,
it even gets compiled, but it won't get used. If that method gets fixed in XSLTCDTMManager
or its ancestor, then this method might be used instead, giving a much simpler and cleaner
implementation. If some of my code would be useful for such an implementation as well, like
the check for "is same DOM", feel free to copy or move my code to those classes as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782251#action_12782251
]
Michael Glavassevich commented on XALANJ-2493:
----------------------------------------------
Probably not a good idea to start introducing dependencies on higher JDKs without discussing
with the community. Xerces is also still on JDK 1.3 (because we have users who are still
on that level; probably some of them use Xalan too) and relies on Xalan's serializer also
being at that level.
> 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: The Latest Development Code
> Reporter: Martin von Gagern
> Attachments: XALANJ-2493_1.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 generate from a DOM source to be a DOM2DTM, which SAXImpl is not. A comment
inside that method also indicates that future implementations might drop auto-importing and
instead leave it to the caller to import a DOM if it hasn't been imported before.
> I left my own attempt at an nodeList2Iterator implementation using getDTMHandleFromNode
in place, renamed to nodeList2IteratorUsingHandleFromNode and made private. So it's there,
it even gets compiled, but it won't get used. If that method gets fixed in XSLTCDTMManager
or its ancestor, then this method might be used instead, giving a much simpler and cleaner
implementation. If some of my code would be useful for such an implementation as well, like
the check for "is same DOM", feel free to copy or move my code to those classes as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782216#action_12782216
]
Martin von Gagern commented on XALANJ-2493:
-------------------------------------------
It's a language feature: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/AssertionError.html
I just realized that this is "fairly new", added in JDK 1.4, while Xalan according to its
FAQ seems to still support 1.3. So I guess I'll have to rewrite my patch, either without assertions
or with some other class for their errors.
> 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: The Latest Development Code
> Reporter: Martin von Gagern
> Attachments: XALANJ-2493_1.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 generate from a DOM source to be a DOM2DTM, which SAXImpl is not. A comment
inside that method also indicates that future implementations might drop auto-importing and
instead leave it to the caller to import a DOM if it hasn't been imported before.
> I left my own attempt at an nodeList2Iterator implementation using getDTMHandleFromNode
in place, renamed to nodeList2IteratorUsingHandleFromNode and made private. So it's there,
it even gets compiled, but it won't get used. If that method gets fixed in XSLTCDTMManager
or its ancestor, then this method might be used instead, giving a much simpler and cleaner
implementation. If some of my code would be useful for such an implementation as well, like
the check for "is same DOM", feel free to copy or move my code to those classes as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782185#action_12782185
]
Henry Zongaro commented on XALANJ-2493:
---------------------------------------
Hi, Martin.
I was just trying out your patch and was tripped up by the references to an AssertionError
constructor. Where is that class defined?
> 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: The Latest Development Code
> Reporter: Martin von Gagern
> Attachments: XALANJ-2493_1.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 generate from a DOM source to be a DOM2DTM, which SAXImpl is not. A comment
inside that method also indicates that future implementations might drop auto-importing and
instead leave it to the caller to import a DOM if it hasn't been imported before.
> I left my own attempt at an nodeList2Iterator implementation using getDTMHandleFromNode
in place, renamed to nodeList2IteratorUsingHandleFromNode and made private. So it's there,
it even gets compiled, but it won't get used. If that method gets fixed in XSLTCDTMManager
or its ancestor, then this method might be used instead, giving a much simpler and cleaner
implementation. If some of my code would be useful for such an implementation as well, like
the check for "is same DOM", feel free to copy or move my code to those classes as well.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Hello Henry! Henry Zongaro wrote: > Coincidentally, I was just getting myself set up to spend some time > reviewing some of your patches as I'd promised. If those look good, I > wouldn't see any impediment to nominating you for committer status. Have you found any time yet? You will keep those reviews in mind, right? Greetings, Martin
[ https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781586#action_12781586
]
Henry Zongaro commented on XALANJ-2510:
---------------------------------------
Sorry - I was just getting caught up on the e-mail thread associated with this. You wrote,
"nope, they can't...trust me :)
It's a very advanced extension library with significant nested structure...to represent it
as a sequence of nested function calls would be too complex and difficult to read/maintain...if
it could be done at all.
The example I gave was an extremely simple use case to get across what I want to do, rather
than get bogged down in the particulars of each use case. I understand the use of functions,
my extension library has a whole bunch of extension functions (I think it's up to about 30)...but
also has about 40 extension elements for structures that are just too complex to be represented
as extension functions. Some of these extension elements have return values that don't suit
being turned into a node set."
> Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)
> -------------------------------------------------------------------------------------
>
> Key: XALANJ-2510
> URL: https://issues.apache.org/jira/browse/XALANJ-2510
> 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-extensions
> Affects Versions: The Latest Development Code
> Reporter: Adam Jenkins
> Fix For: The Latest Development Code
>
> Attachments: XALANJ-2510.patch
>
>
> When using extension elements, there is no way to set a non XRTreeFrag related variable.
> For example, say you have:
> <xsl:variable name="myvar">
> <my:extension someAttribute="somevalue"/>
> </xsl:variable>
> If my:extension wants to set a tree fragment, string or nodeset into myvar, that's not
a problem, however if it wants to set a java object, currently there is no mechanism for that
(any java object passed either returned from the method or passed to XSLProcessorContext.outputToResultTree
is toString()'ed before being passed back to the ElemVariable.getValue() method).
> The proposed change (patch supplied) is to supply an optional variable on ElemVariable.java
whereby child extension elements can call up to their parent and set an XPath to be evaluated
after the extension element has finished processing.
> This requires only very minor modification to the ElemVariable.getValue method to check
this variable.
> This also ensures that this is optional functionality and will not affect that basic
Xalan processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781581#action_12781581
]
Henry Zongaro commented on XALANJ-2510:
---------------------------------------
Adam, could I ask you elaborate on the motivation for this change? It's not clear to me why
using an extension function instead wouldn't work. Having an extension element return something
other nodes feels odd to me for XSLT 1.0.
> Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)
> -------------------------------------------------------------------------------------
>
> Key: XALANJ-2510
> URL: https://issues.apache.org/jira/browse/XALANJ-2510
> 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-extensions
> Affects Versions: The Latest Development Code
> Reporter: Adam Jenkins
> Fix For: The Latest Development Code
>
> Attachments: XALANJ-2510.patch
>
>
> When using extension elements, there is no way to set a non XRTreeFrag related variable.
> For example, say you have:
> <xsl:variable name="myvar">
> <my:extension someAttribute="somevalue"/>
> </xsl:variable>
> If my:extension wants to set a tree fragment, string or nodeset into myvar, that's not
a problem, however if it wants to set a java object, currently there is no mechanism for that
(any java object passed either returned from the method or passed to XSLProcessorContext.outputToResultTree
is toString()'ed before being passed back to the ElemVariable.getValue() method).
> The proposed change (patch supplied) is to supply an optional variable on ElemVariable.java
whereby child extension elements can call up to their parent and set an XPath to be evaluated
after the extension element has finished processing.
> This requires only very minor modification to the ElemVariable.getValue method to check
this variable.
> This also ensures that this is optional functionality and will not affect that basic
Xalan processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780478#action_12780478
]
Eric Wout van der Steen commented on XALANJ-2409:
-------------------------------------------------
We've just switched to Xalan 2.7.1 (from Xalan 2.7.0 with Xerces 2.7.1) and see the same effect.
> LSSerializerImpl adds redundant xmlns:xml namespace bindings.
> -------------------------------------------------------------
>
> Key: XALANJ-2409
> URL: https://issues.apache.org/jira/browse/XALANJ-2409
> Project: XalanJ2
> Issue Type: Bug
> Components: Serialization
> Reporter: Chris Simmons
> Attachments: boundxmlprefix.xml, patch3092.txt, TestSerializer.java
>
>
> We switched over when the xerces serializers were deprecated but found tha the xalan
serializer insists on adding bindings for the xml namespace. I (and the xerces serializer)
believe that this is not necessary - the xml namespace is built-in.
> This resulted in our XML being littered with thousands of needless xmlns:xml=... attributes.
We've worked around this by making sure we put one on the document root. I'd like to see
these attributes not serialized.
> I'll attach a test showing this behviour shortly. It shows that xerces didn't add them
but xalan does.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Hi Guys,
Can someone cast a quick eye over XALANJ-2510. It's a very simply improvement that has a
patch supplied, probably take less than 5 minutes to approve. The consultancy I work for
is on my back about it because we have an open source library that depends on it that we're
itching to release into the wild.
Cheers
Adam
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Transformer failed to transform DomSource to StreamResult, if the StreamResult is created with
a File and the file name contain space charactor
-----------------------------------------------------------------------------------------------------------------------------------------------
Key: XALANJ-2511
URL: https://issues.apache.org/jira/browse/XALANJ-2511
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: Windows Server 2003
Reporter: Owen Chang
Problem:
I use the transformer to write a dom document to a file, so I use a DOMSource, and a StreamResult.
I create a Stream Result using the contructor:
public StreamResult(File f)
and the file path I used includes space charactor, like "E:\Program Files\XXXX.xsd", and I
run it, the error occurs:
java.io.FileNotFoundException: E:\Program%20Files\XXXX.xsd
Analysis:
When I create the StreamResult, the constructor call its setSystemId method, in that method,
the file path is converted to a URI, the code like this:
this.systemId = f.toURI().toString();
So, The systemId stored in StreamResult is like:
file:\\\E:\Program%20Files\XXXX.xsd
But in the TransformerIdentityImpl(org.apache.xalan.transformer)'s createResultContentHandler
method, it convert the uri to filepath and use FileOutputStream to open the file. The convert
logic is as following:
String fileURL = sresult.getSystemId();
if (fileURL.startsWith("file:///")) {
if (fileURL.substring(8).indexOf(":") >0) {
fileURL = fileURL.substring(8);
} else {
fileURL = fileURL.substring(7);
}
} else if (fileURL.startsWith("file:/")) {
if (fileURL.substring(6).indexOf(":") >0) {
fileURL = fileURL.substring(6);
} else {
fileURL = fileURL.substring(5);
}
}
The problem is that it does not decode the %20 charactor to space charactor.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
Ability to set non tree fragment variable using an extension element (PATCH SUPPLIED)
-------------------------------------------------------------------------------------
Key: XALANJ-2510
URL: https://issues.apache.org/jira/browse/XALANJ-2510
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-extensions
Affects Versions: The Latest Development Code
Reporter: Adam Jenkins
Fix For: The Latest Development Code
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
keshlam@us.ibm.com wrote: > Conceptually the changes would all be local to xsl:variable. But I find > myself nervous about whether and how they would propagate through the > rest of the system -- whether we might wind up relaxing typechecking > elsewhere and losing some of the strength of error detection. Allowing references to arbitrary objects to be stored in variables is a powerful thing indeed. Should be possible even now through the use of extension functions instead of extension elkements. There are some issues though, e.g. https://issues.apache.org/jira/browse/XALANJ-1847 Greetings, Martin von Gagern
> Is it that big an ask to be able to set a variable from an extension element? Specifically, to set a variable to something other than XPath-compatable data, since of course the syntax you show already works for result tree fragments... ... I'm really not sure. Probably worth drafting a prototype to see just how much it affects. Don't forget to consider both compiled and interpreted modes, and to make sure it's not going to adversely affect performance when the new feature is not in use. Conceptually the changes would all be local to xsl:variable. But I find myself nervous about whether and how they would propagate through the rest of the system -- whether we might wind up relaxing typechecking elsewhere and losing some of the strength of error detection. Personally, I'm always nervous about extensions generally, given their inherent nonportability and the debugging hassles they can entail. With the exception of the EXSLT set -- much of which was folded into XSLT 2.0, and all of which was designed to be fairly cleanly isolatable/reimplementable -- I've seen them misused more often than I've seen them used well. If I were in your shoes, I would be thinking more in terms of creating a separate preprocessing stage (possibly taking advantage of Xalan's XPath support) than embedding the new language into the XSLT stylesheet; that would be a much more robust solution. ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html)
nope, they can't...trust me :)
It's a very advanced extension library with significant nested structure...to represent it
as a sequence of nested function calls would be too complex and difficult to read/maintain...if
it could be done at all.
The example I gave was an extremely simple use case to get across what I want to do, rather
than get bogged down in the particulars of each use case. I understand the use of functions,
my extension library has a whole bunch of extension functions (I think it's up to about 30)...but
also has about 40 extension elements for structures that are just too complex to be represented
as extension functions. Some of these extension elements have return values that don't suit
being turned into a node set.
Is it that big an ask to be able to set a variable from an extension element? The patch submitted
doesn't seem overly complex or have any impact on any other part of Xalan???
--- On Mon, 16/11/09, keshlam@us.ibm.com <keshlam@us.ibm.com> wrote:
> From: keshlam@us.ibm.com <keshlam@us.ibm.com>
> Subject: Re: Advanced Extension Element Question
> To: xalan-dev@xml.apache.org
> Received: Monday, 16 November, 2009, 3:43 PM
> I'm
> still not sure I understand why you
> feel you have to express this as extension elements, when
> extension functions
> can already do what you (appear to) need?
>
>
>
> ______________________________________
>
> "... Three things see no end: A loop with exit code
> done wrong,
>
> A semaphore untested, And the change that comes along.
> ..."
>
> -- "Threes" Rev 1.1 - Duane Elms / Leslie
> Fish (http://www.ovff.org/pegasus/songs/threes-rev-11.html)
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
I'm still not sure I understand why you feel you have to express this as extension elements, when extension functions can already do what you (appear to) need? ______________________________________ "... Three things see no end: A loop with exit code done wrong, A semaphore untested, And the change that comes along. ..." -- "Threes" Rev 1.1 - Duane Elms / Leslie Fish ( http://www.ovff.org/pegasus/songs/threes-rev-11.html)
I've implemented the strategy below on a local copy and it seems to work fine, comments on
the attached patch are very welcome.
What is the escalation process to have a patch like this incorporated into the next release?
--- On Sun, 15/11/09, Adam Jenkins <adamjenkinstmpredirect@yahoo.com.au> wrote:
> From: Adam Jenkins <adamjenkinstmpredirect@yahoo.com.au>
> Subject: Re: Advanced Extension Element Question
> To: xalan-dev@xml.apache.org
> Received: Sunday, 15 November, 2009, 8:49 AM
> damn it...every single avenue I go
> down for adding a variable value from an extension element
> is a dead end (and I'm pullin' some crazy hacks at this
> stage).
>
> this seems like a pretty big deficiency in the extension
> element framework...I have an open source library that does
> some pretty cool stuff scheduled for release, however the
> only limitation is that for two of the new elements, I can't
> add variables to the stack from an extension element.
>
> Is there anyway we can get this into the next release of
> Xalan, I'm happy to code it up myself and submit a patch if
> someone can give architectural guidance?
>
> My perfect world scenario would be for something like
> this:
>
> <xsl:variable name="somename">
> <my:extensionElement
> someattr="value"/>
> </xsl:variable>
>
> And have the method of the extension element somehow supply
> an XObject back to the parent.
>
> This may be a simple as adding a method to the ElemVariable
> class that is something like setChildDrivenSelect(XPath p)
> and modify the getValue() method so that if that method is
> called during child evaluation, it returns the evaluation of
> the supplied XPath rather than returning the XRTreeFrag from
> the child.
>
> That way if we wanted to do this functionality we could
> code our extension elements thus:
>
> public void extensionElement(XSLProcessorContext ctx,
> ElemExtensionCall elem){
> Object myValue = ...do some stuff...
> ElemVariable varElement =
> (ElemVariable)elem.getParent();
> varElement.setChildDrivenSelect(new
> XPath(new XObject(myValue)));
> }
>
> How does everyone feel about that change? It's quick,
> easy and offers some pretty spectacular functionality for
> very little modification. We'd just have to replace
> the line in ElemVariable.getValue()
>
> var = new XRTreeFrag(df, xctxt, this);
>
> with
>
> if(childPopulatedXPath == null) var = new XRTreeFrag(df,
> xctxt, this);
> else var = childPopulatedXPath.execute(xctxt, sourceNode,
> this);
>
> Thoughts/Comments?
>
> Doing this allows for some pretty cool extension elements
> to be built which would really take Xalan to another level.
>
> Cheers
> Adam
> --- On Sat, 14/11/09, keshlam@us.ibm.com
> <keshlam@us.ibm.com>
> wrote:
>
> > From: keshlam@us.ibm.com
> <keshlam@us.ibm.com>
> > Subject: Re: Advanced Extension Element Question
> > To:
> > Cc: xalan-dev@xml.apache.org,
> xalan-j-users@xml.apache.org
> > Received: Saturday, 14 November, 2009, 8:29 AM
> > > Can anyone tell me
> > if there's any way to add an
> > object (not node or
> >
> > > tree fragment) variable to the variable stack
> from an
> > extension element?
> >
> >
> >
> > From an extension _element_... I
> > don't think so.
> >
> >
> >
> >
> >
> > From an extension _function_, yes. If
> > the returned
> > value is not an instanceof one of the types called out
> in
> > the mapping table
> > (http://xml.apache.org/xalan-j/extensions.html#ext-functions),
> > it will be returned as an object reference. Generally
> you
> > can't do much
> > with those except store them in variables and/or pass
> them
> > as parameters
> > to other extensions.
> >
> >
> >
> > If your returned value *is* an
> > instanceof one of those
> > types... The best suggestion I can give you is to set
> up a
> > wrapper object
> > which does not implement those types, return the
> wrapper,
> > and have whoever
> > is using the value unwrap it again before accessing
> > it.
>
>
>
> __________________________________________________________________________________
> Win 1 of 4 Sony home entertainment packs thanks to
> Yahoo!7.
> Enter now: http://au.docs.yahoo.com/homepageset/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org
>
>
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
damn it...every single avenue I go down for adding a variable value from an extension element
is a dead end (and I'm pullin' some crazy hacks at this stage).
this seems like a pretty big deficiency in the extension element framework...I have an open
source library that does some pretty cool stuff scheduled for release, however the only limitation
is that for two of the new elements, I can't add variables to the stack from an extension
element.
Is there anyway we can get this into the next release of Xalan, I'm happy to code it up myself
and submit a patch if someone can give architectural guidance?
My perfect world scenario would be for something like this:
<xsl:variable name="somename">
<my:extensionElement someattr="value"/>
</xsl:variable>
And have the method of the extension element somehow supply an XObject back to the parent.
This may be a simple as adding a method to the ElemVariable class that is something like setChildDrivenSelect(XPath
p) and modify the getValue() method so that if that method is called during child evaluation,
it returns the evaluation of the supplied XPath rather than returning the XRTreeFrag from
the child.
That way if we wanted to do this functionality we could code our extension elements thus:
public void extensionElement(XSLProcessorContext ctx, ElemExtensionCall elem){
Object myValue = ...do some stuff...
ElemVariable varElement = (ElemVariable)elem.getParent();
varElement.setChildDrivenSelect(new XPath(new XObject(myValue)));
}
How does everyone feel about that change? It's quick, easy and offers some pretty spectacular
functionality for very little modification. We'd just have to replace the line in ElemVariable.getValue()
var = new XRTreeFrag(df, xctxt, this);
with
if(childPopulatedXPath == null) var = new XRTreeFrag(df, xctxt, this);
else var = childPopulatedXPath.execute(xctxt, sourceNode, this);
Thoughts/Comments?
Doing this allows for some pretty cool extension elements to be built which would really take
Xalan to another level.
Cheers
Adam
--- On Sat, 14/11/09, keshlam@us.ibm.com <keshlam@us.ibm.com> wrote:
> From: keshlam@us.ibm.com <keshlam@us.ibm.com>
> Subject: Re: Advanced Extension Element Question
> To:
> Cc: xalan-dev@xml.apache.org, xalan-j-users@xml.apache.org
> Received: Saturday, 14 November, 2009, 8:29 AM
> > Can anyone tell me
> if there's any way to add an
> object (not node or
>
> > tree fragment) variable to the variable stack from an
> extension element?
>
>
>
> From an extension _element_... I
> don't think so.
>
>
>
>
>
> From an extension _function_, yes. If
> the returned
> value is not an instanceof one of the types called out in
> the mapping table
> (http://xml.apache.org/xalan-j/extensions.html#ext-functions),
> it will be returned as an object reference. Generally you
> can't do much
> with those except store them in variables and/or pass them
> as parameters
> to other extensions.
>
>
>
> If your returned value *is* an
> instanceof one of those
> types... The best suggestion I can give you is to set up a
> wrapper object
> which does not implement those types, return the wrapper,
> and have whoever
> is using the value unwrap it again before accessing
> it.
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
keshlam@us.ibm.com wrote: > I believe there is a sketch of a "document cursor" abstraction, called > XDM, checked into the Xalan repository. That sounds promising. Will have a look when I find the time. -- Martin
[ https://issues.apache.org/jira/browse/XALANJ-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated XALANJ-656:
-------------------------
Comment: was deleted
(was: [best casino|http://devel-rok.informatik.hu-berlin.de/bugzilla/attachment.cgi?id=30])
> <xsl:copy> introduces inappropriate line-end characters processing comments
> ---------------------------------------------------------------------------
>
> Key: XALANJ-656
> URL: https://issues.apache.org/jira/browse/XALANJ-656
> Project: XalanJ2
> Issue Type: Bug
> Components: Xalan
> Affects Versions: 2.2.0
> Environment: Operating System: MacOS 9
> Platform: Macintosh
> Reporter: Angus McIntyre
> Assignee: Xalan Developers Mailing List
> Priority: Minor
>
> I was trying to write a template that would correctly reproduce the script
> body of a JavaScript (which is typically 'masked' by a comment). My initial
> attempt was:
> <xsl:template match="script/comment()">
> <xsl:copy/>
> </xsl:template>
> which worked, except that the copied script contained newline (ASCII 10)
> in place of the carriage-return (ASCII 13) characters in the original. Note
> that this is on a Macintosh, where line-endings are terminated by CR
> rather than LF; I suspect it wouldn't manifest as a problem on UN*X). My
> guess is that in this case, <xsl:copy> is causing Xalan to simply write LF's
> rather than the appropriate platform-specific line terminators.
> A workaround is to use:
> <xsl:template match="script/comment()">
> <xsl:comment><xsl:value-of select="."/></xsl:comment>
> </xsl:template>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated XALANJ-656:
-------------------------
Comment: was deleted
(was: [beste casino|http://devel-rok.informatik.hu-berlin.de/bugzilla/attachment.cgi?id=30])
> <xsl:copy> introduces inappropriate line-end characters processing comments
> ---------------------------------------------------------------------------
>
> Key: XALANJ-656
> URL: https://issues.apache.org/jira/browse/XALANJ-656
> Project: XalanJ2
> Issue Type: Bug
> Components: Xalan
> Affects Versions: 2.2.0
> Environment: Operating System: MacOS 9
> Platform: Macintosh
> Reporter: Angus McIntyre
> Assignee: Xalan Developers Mailing List
> Priority: Minor
>
> I was trying to write a template that would correctly reproduce the script
> body of a JavaScript (which is typically 'masked' by a comment). My initial
> attempt was:
> <xsl:template match="script/comment()">
> <xsl:copy/>
> </xsl:template>
> which worked, except that the copied script contained newline (ASCII 10)
> in place of the carriage-return (ASCII 13) characters in the original. Note
> that this is on a Macintosh, where line-endings are terminated by CR
> rather than LF; I suspect it wouldn't manifest as a problem on UN*X). My
> guess is that in this case, <xsl:copy> is causing Xalan to simply write LF's
> rather than the appropriate platform-specific line terminators.
> A workaround is to use:
> <xsl:template match="script/comment()">
> <xsl:comment><xsl:value-of select="."/></xsl:comment>
> </xsl:template>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated XALANJ-656:
-------------------------
Comment: was deleted
(was: [bet casino|http://devel-rok.informatik.hu-berlin.de/bugzilla/attachment.cgi?id=30])
> <xsl:copy> introduces inappropriate line-end characters processing comments
> ---------------------------------------------------------------------------
>
> Key: XALANJ-656
> URL: https://issues.apache.org/jira/browse/XALANJ-656
> Project: XalanJ2
> Issue Type: Bug
> Components: Xalan
> Affects Versions: 2.2.0
> Environment: Operating System: MacOS 9
> Platform: Macintosh
> Reporter: Angus McIntyre
> Assignee: Xalan Developers Mailing List
> Priority: Minor
>
> I was trying to write a template that would correctly reproduce the script
> body of a JavaScript (which is typically 'masked' by a comment). My initial
> attempt was:
> <xsl:template match="script/comment()">
> <xsl:copy/>
> </xsl:template>
> which worked, except that the copied script contained newline (ASCII 10)
> in place of the carriage-return (ASCII 13) characters in the original. Note
> that this is on a Macintosh, where line-endings are terminated by CR
> rather than LF; I suspect it wouldn't manifest as a problem on UN*X). My
> guess is that in this case, <xsl:copy> is causing Xalan to simply write LF's
> rather than the appropriate platform-specific line terminators.
> A workaround is to use:
> <xsl:template match="script/comment()">
> <xsl:comment><xsl:value-of select="."/></xsl:comment>
> </xsl:template>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated XALANJ-656:
-------------------------
Comment: was deleted
(was: [beste casino|http://devel-rok.informatik.hu-berlin.de/bugzilla/attachment.cgi?id=30])
> <xsl:copy> introduces inappropriate line-end characters processing comments
> ---------------------------------------------------------------------------
>
> Key: XALANJ-656
> URL: https://issues.apache.org/jira/browse/XALANJ-656
> Project: XalanJ2
> Issue Type: Bug
> Components: Xalan
> Affects Versions: 2.2.0
> Environment: Operating System: MacOS 9
> Platform: Macintosh
> Reporter: Angus McIntyre
> Assignee: Xalan Developers Mailing List
> Priority: Minor
>
> I was trying to write a template that would correctly reproduce the script
> body of a JavaScript (which is typically 'masked' by a comment). My initial
> attempt was:
> <xsl:template match="script/comment()">
> <xsl:copy/>
> </xsl:template>
> which worked, except that the copied script contained newline (ASCII 10)
> in place of the carriage-return (ASCII 13) characters in the original. Note
> that this is on a Macintosh, where line-endings are terminated by CR
> rather than LF; I suspect it wouldn't manifest as a problem on UN*X). My
> guess is that in this case, <xsl:copy> is causing Xalan to simply write LF's
> rather than the appropriate platform-specific line terminators.
> A workaround is to use:
> <xsl:template match="script/comment()">
> <xsl:comment><xsl:value-of select="."/></xsl:comment>
> </xsl:template>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
[ https://issues.apache.org/jira/browse/XALANJ-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated XALANJ-656:
-------------------------
Comment: was deleted
(was: [best online casino|https://lists.umbc.edu/lists/d_read/1211/best-casino.html]
[deposit casino bonus|https://lists.umbc.edu/lists/d_read/1211/casino-bonus.html]
[free casino games download|https://lists.umbc.edu/lists/d_read/1211/casino-free-games.html]
[casino glucksspiel|https://lists.umbc.edu/lists/d_read/1211/casino-glucksspiel.html]
[casino hotel
|https://lists.umbc.edu/lists/d_read/1211/casino-hotel.html]
[casinos online|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=61]
[casino slot machines|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=63]
[casino spiele|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=64]
[casino und hotel|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=66]
[casino hotel|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=67]
[online kasino bonus|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=69]
[free casino online games|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=70]
[freies kasino|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=71]
[casino & hotel|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=72]
[kasino go higher|https://lists.umbc.edu/lists/d_read/1211/kasino-hotel.html]
[kasino spiel|https://lists.umbc.edu/lists/d_read/1211/kasino-spiele.html]
[888 kasino|https://lists.umbc.edu/lists/d_read/1211/kasino-und-hotel.html]
[online kasino|https://lists.umbc.edu/lists/d_read/1211/kasino.html]
[kasinos online|https://lists.umbc.edu/lists/d_read/1211/kasinos-online.html]
[kasino go higher|https://lists.umbc.edu/lists/d_read/1211/kasinos.html]
[kostenlos casinospiele|https://lists.umbc.edu/lists/d_read/1211/kostenlose-casinospiele.html]
[casino free no deposit|https://lists.umbc.edu/lists/d_read/1211/no-deposit-casino.html]
[online casino|https://lists.umbc.edu/lists/d_read/1211/online-casino.html]
[online kasino
|https://lists.umbc.edu/lists/d_read/1211/online-kasino.html]
[resort hotel casino|https://lists.umbc.edu/lists/d_read/1211/resort-casino.html]
)
> <xsl:copy> introduces inappropriate line-end characters processing comments
> ---------------------------------------------------------------------------
>
> Key: XALANJ-656
> URL: https://issues.apache.org/jira/browse/XALANJ-656
> Project: XalanJ2
> Issue Type: Bug
> Components: Xalan
> Affects Versions: 2.2.0
> Environment: Operating System: MacOS 9
> Platform: Macintosh
> Reporter: Angus McIntyre
> Assignee: Xalan Developers Mailing List
> Priority: Minor
>
> I was trying to write a template that would correctly reproduce the script
> body of a JavaScript (which is typically 'masked' by a comment). My initial
> attempt was:
> <xsl:template match="script/comment()">
> <xsl:copy/>
> </xsl:template>
> which worked, except that the copied script contained newline (ASCII 10)
> in place of the carriage-return (ASCII 13) characters in the original. Note
> that this is on a Macintosh, where line-endings are terminated by CR
> rather than LF; I suspect it wouldn't manifest as a problem on UN*X). My
> guess is that in this case, <xsl:copy> is causing Xalan to simply write LF's
> rather than the appropriate platform-specific line terminators.
> A workaround is to use:
> <xsl:template match="script/comment()">
> <xsl:comment><xsl:value-of select="."/></xsl:comment>
> </xsl:template>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
> Can anyone tell me if there's any way to add an object (not node or > tree fragment) variable to the variable stack from an extension element? >From an extension _element_... I don't think so. >From an extension _function_, yes. If the returned value is not an instanceof one of the types called out in the mapping table ( http://xml.apache.org/xalan-j/extensions.html#ext-functions), it will be returned as an object reference. Generally you can't do much with those except store them in variables and/or pass them as parameters to other extensions. If your returned value *is* an instanceof one of those types... The best suggestion I can give you is to set up a wrapper object which does not implement those types, return the wrapper, and have whoever is using the value unwrap it again before accessing it.
Can anyone tell me if there's any way to add an object (not node or tree fragment) variable
to the variable stack from an extension element?
I originally tried to use context.outputToResultTree(context.getStylesheet(), myCreatedObject)
an put my extension element inside an <xsl:variable...>, however that turns my java
object into a text node on a Document first (the text node has the value of the toString()
from my object) rather than passing myCreatedObject to the ElemVariable element as a java
object.
I'm now looking into doing a similar thing as in ElemVariable.java and adding the object to
the stack directly from within my extension element method, from what I can see, this should
work:
StylesheetRoot root = xslProcessorContext.getStylesheet().getStylesheetRoot();
StylesheetRoot.ComposeState cstate = sroot.getComposeState();
QName name = new QName(name);
XObject obj = new XObject(myCreatedObject);
int index = cstate.addVariableName(name) - cstate.getGlobalsSize();
xslProcessorContext.getTransformer().getXPathContext().getVarStack().setLocalVariable(index,
obj);
Now this is similar to what ElemVariable.java does, however StylesheetRoot.ComposeState is
package scoped!, so I can't use the above code either :(
If anyone knows of a way to put a java object variable onto the variable stack (as an XObject,
not a XRTreeFrag) under a given name from within an extension element method I'd really appreciate
any pointers you could give.
My goals is placing an object into the local variable stack under a given name so that I can
reference it, for example in an <xsl:value-of select="java:someMethod($myPreviouslyAddedObject)"/>
--- On Fri, 13/11/09, Adam Jenkins <adamjenkinstmpredirect@yahoo.com.au> wrote:
> From: Adam Jenkins <adamjenkinstmpredirect@yahoo.com.au>
> Subject: Advanced Extension Element Question
> To: xalan-j-users@xml.apache.org, xalan-dev@xml.apache.org
> Received: Friday, 13 November, 2009, 5:53 PM
> Hi All,
>
> I'm just wondering if there is a way to place a java object
> (not a tree fragment) into the context output results from
> an extension element, and have it stay as an object (and not
> have it turned into a Document node).
>
> Here is the exact use case. I have a custom extension
> that creates an object that is used later on throughout my
> xslt. The use case I want is:
>
> <xsl:variable name="somevarname">
> <custom:myobject>
> <custom:property name="blah"
> value="blah"/>
> </custom:myobject>
> </xsl:variable>
>
> The function myObject(XSLProcessorContext,
> ElemExtensionCall) on the object mapped to the prefix
> 'custom' creates a java object, and places it to the output
> tree thus:
>
> context.outputToResultTree(context.getStylesheet(),
> myCreatedObject);
>
> Now, when I try to reference that later, it's been turned
> into a text node on a Document object whos value is the
> value of the toString() method for 'myCreatedObject'.
> So I think I'm using the wrong method here...and that
> perhaps there's a better method other than
> outputToResultTree??
>
> So I'm guessing xalan <xsl:variable...> tag is
> creating a document fragment from my object as best it can.
>
> So my question is...is there anyway, to pass
> myCreatedObject up to the previous <xsl:variable...>
> declaration without it being toStringed (another method
> somewhere).
>
> My fallback is to declare a varName attribute on all my
> custom extension and put the object on the local variable
> stack myself, but that's a pain and looks ugly, I'd prefer
> to do it using xsl:variable.
>
> This is for an open source (large) xalan extension library
> to be releases asap.
>
> Cheers
> Adam
>
>
>
> __________________________________________________________________________________
> Win 1 of 4 Sony home entertainment packs thanks to
> Yahoo!7.
> Enter now: http://au.docs.yahoo.com/homepageset/
>
__________________________________________________________________________________
Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7.
Enter now: http://au.docs.yahoo.com/homepageset/
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org
> > If I were to write an xslt processor from scratch, I'd either drop DTM > > altogether, or have the transformation work on some interface which can > > be provided from both DOM and DTM. I'd also try to get some closer > > integration between the xslt interpreter and the xsltc compiler, i.e. > > have a bunch of classes, each with methods compile() and interpret(), so > > people could more easily ensure they perform the same operations. I believe there is a sketch of a "document cursor" abstraction, called XDM, checked into the Xalan repository. Our plan had been to migrate Xalan to running over XDM, making DTM strictly a back-end representation and allowing an XDM that ran directly over the DOM rather than the current kluge of wrapping DOMs in a partial DTM. This would also make plugging in other data models easier, if you wanted to run across JDOM (ugh) or some custom model used by a particular application. I did some additional (unpublished) work on XDM before setting it aside, so I can attest that the approach is viable. Retrofitting it into the processor would not be a small task -- it's on the same order of magnitude as the work we did rewriting XSLTC to share DTM with the interpreter -- but would certainly be doable. The result would be a somewhat cleaner architecture.
Just a suggestion that if you are going to look into XSLT 2, you might want to look at using the PsychoPath XPath 2.0 processor for the XPath 2.0 support. It is fully schema aware, and is open source under an Eclipse Public License. The Xerces-J project is using it for their XPath 2.0 assertion support for XML Schema 1.1. http://wiki.eclipse.org/PsychoPathXPathProcessor/UserManual Dave Martin von Gagern wrote: > Henry Zongaro wrote: > >> Coincidentally, I was just getting myself set up to spend some time >> reviewing some of your patches as I'd promised. If those look good, I >> wouldn't see any impediment to nominating you for committer status. >> > > That's really good to hear! > > >> One weakness of XSLTC is in its error checking. It's nowhere near as >> thorough as the Xalan-J interpreter in that respect. That's something >> that could be remedied by having them share their abstract syntax tree >> representations - common classes with compile() and interpret() methods >> as you suggest. >> > > Maybe I'll start a code branch working towards that direction, once I > have access to the svn repository... > > -- Martin > > --------------------------------------------------------------------- To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org For additional commands, e-mail: xalan-dev-help@xml.apache.org
Henry Zongaro wrote: > Coincidentally, I was just getting myself set up to spend some time > reviewing some of your patches as I'd promised. If those look good, I > wouldn't see any impediment to nominating you for committer status. That's really good to hear! > One weakness of XSLTC is in its error checking. It's nowhere near as > thorough as the Xalan-J interpreter in that respect. That's something > that could be remedied by having them share their abstract syntax tree > representations - common classes with compile() and interpret() methods > as you suggest. Maybe I'll start a code branch working towards that direction, once I have access to the svn repository... -- Martin
Hi, Martin. Martin von Gagern <Martin.vGagern@gmx.net> wrote on 11/13/2009 11:42:07 AM: > Adam Jenkins wrote: > > I would really like to revive it > > Me, too. > > See http://thread.gmane.org/gmane.text.xml.xalan.devel/17653 > and http://thread.gmane.org/gmane.text.xml.xalan.devel/17705 > and maybe also https://code.launchpad.net/xalan > > > and I have some spare development band width to put towards it, > > I can't make any promises, but I'm willing to contribute some time as > well. Already have, writing a bunch of patches. > > What has me worried is infrastructure. As long as we are not granted > enough access to svn and jira, we won't be able to efficiently use > Apache infrastructure. And as the people around here at least aren't > giving such permissions to anyone dropping by, at least not on a short > timescale, I assume that this will hinder development. > > So my idea is, we might consider moving this development elsewhere. One > possibility would be launchpad, where I've already published an svn > import as well as a branch with some fixes included. Another possibility > might be openjdk, where a copy of xalan forms the basis of the xslt > processor shipped with openjdk, using mercurial as the underlying > revision control system. Or we might prod people around here a bit > harder, to gain the access we require to contribute efficiently. I'm sorry that I haven't been able to contribute to the project over the past year. My other work really hasn't permitted me the time. Coincidentally, I was just getting myself set up to spend some time reviewing some of your patches as I'd promised. If those look good, I wouldn't see any impediment to nominating you for committer status. For whatever it's worth, I think it would be most beneficial for the Xalan-J community if development of the processor continued within this venue. This is the place people are used to going to for questions about Xalan-J and XSLTC, and for help. > If I were to write an xslt processor from scratch, I'd either drop DTM > altogether, or have the transformation work on some interface which can > be provided from both DOM and DTM. I'd also try to get some closer > integration between the xslt interpreter and the xsltc compiler, i.e. > have a bunch of classes, each with methods compile() and interpret(), so > people could more easily ensure they perform the same operations. Certainly that would be better architecturally. The current state of the code reflects the fact that XSLTC and the Xalan-J interpreter were initially developed independent of one another. Some Xalan committers spent quite a lot of time getting them to share more functionally equivalent components. At one point, XSLTC had its own independent implementation of the XPath data model that was similar to DTM. We spent quite a bit of time adapting it to share DTM with the interpreter. It also had its own independent serializer implementation. We spent a lot of time merging those implementations. Overall, I think those changes benefited both processors, in that bugs found by a user of one processor could be fixed for both; performance improvements in DTM or serialization that were targeted to XSLTC could benefit both processors. One weakness of XSLTC is in its error checking. It's nowhere near as thorough as the Xalan-J interpreter in that respect. That's something that could be remedied by having them share their abstract syntax tree representations - common classes with compile() and interpret() methods as you suggest. One other thought - keeping Xalan-J development here, there's a greater potential for cross-pollination of ideas with Xalan-C. For example, if I recall correctly, Xalan-C does its interpretation of a stylesheet in an iterative fashion rather than a recursive fashion. That allows it to process stylesheets that have a much deeper recursive run-time stack than the Xalan-J interpreter. Keeping Xalan-J here makes it easier to share those kinds of ideas. Thanks, Henry ------------------------------------------------------------------ Henry Zongaro XML Transformation & Query Development IBM Canada Lab T/L 313-6044; Phone +1 905 413-6044 mailto:zongaro@ca.ibm.com
Hi Adam, Adam Jenkins wrote: > I would really like to revive it Me, too. See http://thread.gmane.org/gmane.text.xml.xalan.devel/17653 and http://thread.gmane.org/gmane.text.xml.xalan.devel/17705 and maybe also https://code.launchpad.net/xalan > and I have some spare development band width to put towards it, I can't make any promises, but I'm willing to contribute some time as well. Already have, writing a bunch of patches. What has me worried is infrastructure. As long as we are not granted enough access to svn and jira, we won't be able to efficiently use Apache infrastructure. And as the people around here at least aren't giving such permissions to anyone dropping by, at least not on a short timescale, I assume that this will hinder development. So my idea is, we might consider moving this development elsewhere. One possibility would be launchpad, where I've already published an svn import as well as a branch with some fixes included. Another possibility might be openjdk, where a copy of xalan forms the basis of the xslt processor shipped with openjdk, using mercurial as the underlying revision control system. Or we might prod people around here a bit harder, to gain the access we require to contribute efficiently. > Having spent quite a bit of time code diving through Xalan, I also > think it's a pretty good product and pretty good code base...and i > missing something?? My impression is that the whole DTM thing has quite a number of drawbacks. It doesn't interact nicely with garbage collection, imposes pretty tight restrictions on the number of documents and nodes that can be processed, and also imposes some limitations on the interaction with DOM-based extension functions, e.g. with respect to the context of returned DOM nodes, their parents in particular. If I were to write an xslt processor from scratch, I'd either drop DTM altogether, or have the transformation work on some interface which can be provided from both DOM and DTM. I'd also try to get some closer integration between the xslt interpreter and the xsltc compiler, i.e. have a bunch of classes, each with methods compile() and interpret(), so people could more easily ensure they perform the same operations. But on the whole, I believe Xalan is quite a good basis, so I'd rather improve on it than start from scratch. > Is Xalan worth resurrecting and continueing on with? I'd say yes. I hope it can be done. Greetings, Martin von Gagern
Hi Henry! Henry Zongaro wrote on 2009-10-16: > I will try to make some time in November to review your patches. How about it? Will you manage to have a look at them? Greetings, Martin von Gagern
[ https://issues.apache.org/jira/browse/XALANJ-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777435#action_12777435
]
Max commented on XALANJ-656:
----------------------------
[best online casino|https://lists.umbc.edu/lists/d_read/1211/best-casino.html]
[deposit casino bonus|https://lists.umbc.edu/lists/d_read/1211/casino-bonus.html]
[free casino games download|https://lists.umbc.edu/lists/d_read/1211/casino-free-games.html]
[casino glucksspiel|https://lists.umbc.edu/lists/d_read/1211/casino-glucksspiel.html]
[casino hotel
|https://lists.umbc.edu/lists/d_read/1211/casino-hotel.html]
[casinos online|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=61]
[casino slot machines|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=63]
[casino spiele|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=64]
[casino und hotel|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=66]
[casino hotel|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=67]
[online kasino bonus|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=69]
[free casino online games|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=70]
[freies kasino|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=71]
[casino & hotel|https://molior.mcs.suffolk.edu/bugzilla/attachment.cgi?id=72]
[kasino go higher|https://lists.umbc.edu/lists/d_read/1211/kasino-hotel.html]
[kasino spiel|https://lists.umbc.edu/lists/d_read/1211/kasino-spiele.html]
[888 kasino|https://lists.umbc.edu/lists/d_read/1211/kasino-und-hotel.html]
[online kasino|https://lists.umbc.edu/lists/d_read/1211/kasino.html]
[kasinos online|https://lists.umbc.edu/lists/d_read/1211/kasinos-online.html]
[kasino go higher|https://lists.umbc.edu/lists/d_read/1211/kasinos.html]
[kostenlos casinospiele|https://lists.umbc.edu/lists/d_read/1211/kostenlose-casinospiele.html]
[casino free no deposit|https://lists.umbc.edu/lists/d_read/1211/no-deposit-casino.html]
[online casino|https://lists.umbc.edu/lists/d_read/1211/online-casino.html]
[online kasino
|https://lists.umbc.edu/lists/d_read/1211/online-kasino.html]
[resort hotel casino|https://lists.umbc.edu/lists/d_read/1211/resort-casino.html]
> <xsl:copy> introduces inappropriate line-end characters processing comments
> ---------------------------------------------------------------------------
>
> Key: XALANJ-656
> URL: https://issues.apache.org/jira/browse/XALANJ-656
> Project: XalanJ2
> Issue Type: Bug
> Components: Xalan
> Affects Versions: 2.2.0
> Environment: Operating System: MacOS 9
> Platform: Macintosh
> Reporter: Angus McIntyre
> Assignee: Xalan Developers Mailing List
> Priority: Minor
>
> I was trying to write a template that would correctly reproduce the script
> body of a JavaScript (which is typically 'masked' by a comment). My initial
> attempt was:
> <xsl:template match="script/comment()">
> <xsl:copy/>
> </xsl:template>
> which worked, except that the copied script contained newline (ASCII 10)
> in place of the carriage-return (ASCII 13) characters in the original. Note
> that this is on a Macintosh, where line-endings are terminated by CR
> rather than LF; I suspect it wouldn't manifest as a problem on UN*X). My
> guess is that in this case, <xsl:copy> is causing Xalan to simply write LF's
> rather than the appropriate platform-specific line terminators.
> A workaround is to use:
> <xsl:template match="script/comment()">
> <xsl:comment><xsl:value-of select="."/></xsl:comment>
> </xsl:template>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org