Andreas > Issue 1: Since I already implemented the same pattern elsewhere, I can > do it. Your suggestion is a good improvement and we look forward to your contribution.. We implemented the switching into temp files to overcome SYNAPSE-167, and subsequently tested for transformations of around ~15MB, which are common when using the VFS (File) transport. I think we have some unit tests for this as well.. > Issue 2: To solve this one, we need a way to allow XSLTMediator to do > the necessary cleanup after the end of the sequence it is part of (see > the description of SYNAPSE-212 for some ideas about that). As far as I > can see, there is no mechanism in Synapse to do this. Adding this > would require more knowledge of Synapse's internals than I currently > have. This would be a bit tricky to fix correctly.. also one sequence may be called by another sequence, or as the error handling sequence of another etc. We may also have the case where you try to send a message to a dead endpoint (which fails) and then you want to retry the operation again (failover endpoints) etc. > Issue 3: For this one, I would first like to have your feedback on the > two proposed solutions. The second solution can be implemented > straightforwardly, but it should be noted that this requires adding > dependencies on (at least) two JARs from the Spring framework to > Synapse core. We have left the 'useDOMSourceAndResults' flag as the DOM versions of some Axiom documents have has some issues in the past, so that one could fall back to. I don't like Synapse to create DOM compatible trees from the outset.. it may have an overhead, and since one may not be using the XSLT mediator at all in some cases or use something like XQuery or another transformation etc. So I think if the Spring dependency JAR is not huge, we should be fine using it
asankha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
