Hudson build is back to stable: Synapse - Trunk » Apache Synapse - Transports #538
See http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/org.apache.synapse$synapse-transports/538/ - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: VFS Text Files with spaces don't work.
This is not very convincing for several reasons: * An XML parser never removes whitespace. * A validating XML parser reports whitespace _between elements_ in a special way, but it is up to the application to decide what to do with it. Note that we are not talking about this type of whitespace here. * XSLT is not schema aware. * While space=preserve is defined in the XML specs it has no well defined semantics and it is up to the application to interpret it. * Axis2 and Synapse don't (or at least shouldn't) remove any whitespace. What you really need to do is to determine at what step in the mediation the whitespace is lost. Then we can try to understand why this is so. Andreas On Fri, Apr 3, 2009 at 07:19, kimhorn kim.h...@icsglobal.net wrote: You are probably right. Haven't had time to look but I hope the payload text element is defined as space=preserve. If yes then its OK, If not then ? Any idea where is the XSD is easily available ? It is probably one of the mediators removing the white space along the way; as XML does not preserve this. I will have to add in yet again more java to wrap the text field in CDATA . As the recipient cannot change their XSD, this looks like the only optionNot sure XSLT will work unless target name space also defines the element as space preserve ? My simple Synapse script is becoming a massive Java program. And I thought wouldn't it be easy to use a scripting tool like Synapse compared to writing Java code . How wrong. Thanks Kim Andreas Veithen-2 wrote: Are you sure that these spaces get trimmed inside the VFS transport and not somewhere in your mediation? Normally the plain text message builder is designed to strictly preserve the file content (including spaces), so this would be a serious bug. Andreas On Thu, Apr 2, 2009 at 08:52, kimhorn kim.h...@icsglobal.net wrote: Run into a problem with VFS reading text files with fixed field length fields, where empty fields are padded with spaces. There are a number of B2B formats that do this. If the empty fields are at the start or end of the file then when these are inserted into XML as Payload the XML removes the spaces. The text should be wrapped in CDATA with double Quotes to preserve this space data; but VFS does not do this. So the fields at start or end of file get lost and hence the whole file is now garbage. Hopefully reading them as binary files (not plan text) will get over this ? Other ideas ? -- View this message in context: http://www.nabble.com/VFS-Text-Files-with-spaces-don%27t-work.-tp22841970p22841970.html Sent from the Synapse - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org -- View this message in context: http://www.nabble.com/VFS-Text-Files-with-spaces-don%27t-work.-tp22841970p22862146.html Sent from the Synapse - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: startup order - correct place to start transport listeners
I wrote the code to get the engine to wait a maximum number of seconds - for these in-process messages to complete, the callbacks to get replies etc. However, once the graceful timeout specified by a user expires, we shutdown the engine. This code is already within the WSO2 ESB 1.7.x and is valid for Synapse to be brought in. I'd be + 1 to integrate this as a core functionality once Ruwan has finished his work on the startup and shutdown logic. I also share Indika's evaluation that this is a core functionality which should be closely integrated with the other start- and shutup logic. Regards, Eric
[jira] Updated: (SYNAPSE-522) Enhance the Send mediator AND/OR Endpoints, to accept properties
[ https://issues.apache.org/jira/browse/SYNAPSE-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charith Dhanushka Wickramarachchi updated SYNAPSE-522: -- Attachment: synapse-522-2009-04-3.patch This patch enable users to set generic properties inside send mediator and endpoints please review and commit thank you, Charith Enhance the Send mediator AND/OR Endpoints, to accept properties Key: SYNAPSE-522 URL: https://issues.apache.org/jira/browse/SYNAPSE-522 Project: Synapse Issue Type: Improvement Components: Core Affects Versions: 1.2 Reporter: Asankha C. Perera Priority: Minor Fix For: 1.3 Attachments: synapse-522-2009-04-3.patch Reference to http://markmail.org/message/cvbfh2wpapn2yt6u support the specifications of one or more properties within the send mediator e.g. FORCE_HTTP_1.0, POST_TO_PATH etc would belong with the send mediator, while format, passwords etc may belong as endpoint properties send property name=BUILD_ENVELOPE value=true/ ... other such properties.../ endpoint ./ /send OR/AND send endpoint property name=BUILD_ENVELOPE value=true/ ... other such properties.../ /endpoint /send -- 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: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Hudson build became unstable: Synapse - Trunk » Apache Synapse - Transports #539
See http://hudson.zones.apache.org/hudson/job/Synapse%20-%20Trunk/org.apache.synapse$synapse-transports/539/ - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: svn commit: r682108 - /synapse/trunk/java/pom.xml
Indika
Author: indika
Date: Sat Aug 2 23:44:35 2008
New Revision: 682108
URL: http://svn.apache.org/viewvc?rev=682108view=rev
Log:
add commons-cli , this is needed for cipertool and this jar will not be included in the binary distribution
Can you document the use of the ciphertool and its use? Also,
commons-cli is now being included into the binary distribution. Does the
above comment mean that we can exclude it? If so how does one run the
cipher tool? I do not see new scripts etc either.. can you enlighten us?
thanks
asankha
Modified:
synapse/trunk/java/pom.xml
Modified: synapse/trunk/java/pom.xml
URL:
http://svn.apache.org/viewvc/synapse/trunk/java/pom.xml?rev=682108r1=682107r2=682108view=diff
==
--- synapse/trunk/java/pom.xml (original)
+++ synapse/trunk/java/pom.xml Sat Aug 2 23:44:35 2008
@@ -1030,6 +1030,13 @@
version${saxon.version}/version
/dependency
+!--commons-cli --
+dependency
+groupIdcommons-cli/groupId
+artifactIdcommons-cli/artifactId
+version${commons-cli.version}/version
+/dependency
+
/dependencies
+commons-cli.version1.0/commons-cli.version
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Dependency Management with Synapse
I think this is really important, even though I am not sure about how we are going to do the dependency resolution at the startup. One other scenario is that the resource deletion. For the moment, you can delete any of the resource from the SynapseConfiguration through the synapse API. Upon deleting these resource (for example sequences or endpoints) we do not check whether there is a live reference to that particular resource or not. In WSO2 ESB we allow the users to manage the configuration at runtime and this is an important requirement for us to handle on the synapse layer. I propose that we improve the delete methods of the Synapse Configuration in a way that we can pass a boolean value to the delete method which specifies whether you want to cascade delete the entries if there are live references to this entry or to not to delete if there are references. Further, we should be able to see the references for a particular resource in the synapse configuration. Saliya, please create a JIRA issue for this if there are no issues already there in the JIRA for this. Thanks, Ruwan On Fri, Apr 3, 2009 at 6:32 PM, Saliya Ekanayake sal...@wso2.com wrote: Hi, At present Synapse may fail due to dangling references. As an example consider a proxy service which refers to a sequence. If the sequence definition is not there it will be a dangling reference and Synapse will fail to mediate properly. The following items are the possible items on which others may depend. 1. sequences 2. endpoints 3. local entries 4. resources in the registry (remote) A way to overcome the issue is to resolve dependencies at startup. This, however, has an issue since we cannot distinguish between references for local entries and for registry. If we force the user to have all the referring items either in local entries or in registry prior to start Synapse, then we can clearly identify missing resources. Anyway if the user removes a used resource from registry then again Synapse will not be able to handle it. Therefore, IMHO it will be good to omit the dependency management on registry resources. Resolving the remaining dependencies can be achieved by having a list of dependents in each of the 1 - 3 elements. This list can be populated at start time, of course an additional step is necessary to do this. So I would like to know what you folks think about this approach. Thanks, Saliya - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org -- Ruwan Linton Senior Software Engineer Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: Dependency Management with Synapse
Also the delete method should return a boolean specifying whether the deletion is successful or not because with this approach there is an instance where the resource is not going to be deleted even though we call delete. Thanks, Ruwan On Fri, Apr 3, 2009 at 9:34 PM, Ruwan Linton ruwan.lin...@gmail.com wrote: I think this is really important, even though I am not sure about how we are going to do the dependency resolution at the startup. One other scenario is that the resource deletion. For the moment, you can delete any of the resource from the SynapseConfiguration through the synapse API. Upon deleting these resource (for example sequences or endpoints) we do not check whether there is a live reference to that particular resource or not. In WSO2 ESB we allow the users to manage the configuration at runtime and this is an important requirement for us to handle on the synapse layer. I propose that we improve the delete methods of the Synapse Configuration in a way that we can pass a boolean value to the delete method which specifies whether you want to cascade delete the entries if there are live references to this entry or to not to delete if there are references. Further, we should be able to see the references for a particular resource in the synapse configuration. Saliya, please create a JIRA issue for this if there are no issues already there in the JIRA for this. Thanks, Ruwan On Fri, Apr 3, 2009 at 6:32 PM, Saliya Ekanayake sal...@wso2.com wrote: Hi, At present Synapse may fail due to dangling references. As an example consider a proxy service which refers to a sequence. If the sequence definition is not there it will be a dangling reference and Synapse will fail to mediate properly. The following items are the possible items on which others may depend. 1. sequences 2. endpoints 3. local entries 4. resources in the registry (remote) A way to overcome the issue is to resolve dependencies at startup. This, however, has an issue since we cannot distinguish between references for local entries and for registry. If we force the user to have all the referring items either in local entries or in registry prior to start Synapse, then we can clearly identify missing resources. Anyway if the user removes a used resource from registry then again Synapse will not be able to handle it. Therefore, IMHO it will be good to omit the dependency management on registry resources. Resolving the remaining dependencies can be achieved by having a list of dependents in each of the 1 - 3 elements. This list can be populated at start time, of course an additional step is necessary to do this. So I would like to know what you folks think about this approach. Thanks, Saliya - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org -- Ruwan Linton Senior Software Engineer Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com -- Ruwan Linton Senior Software Engineer Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
Re: Synapse dependencies for 1.3
./geronimo-saaj_1.3_spec-1.0.1.jar ./geronimo-ws-metadata_2.0_spec-1.1.2.jar ./serializer-2.7.1.jar ./slf4j-log4j12-1.5.6.jar Not sure about the above 4 :-( serializer-2.7.1.jar is needed for xalan 2.7.1. If you're just referring to what needs to be included in the project pom, the xalan I have declares it as a dep, so it comes in transitively. If you're talking about jars to bundle, it's needed. - Jason --- -- - - - - Please check the full list below for anything I missed, and let me know any other changes or ideas for proper cleanup etc. Current SNAPSHOTS ./axis2-adb-1.5-SNAPSHOT.jar ./axis2-clustering-1.5-SNAPSHOT.jar ./axis2-codegen-SNAPSHOT.jar ./axis2-kernel-1.5-SNAPSHOT.jar ./axis2-mtompolicy-1.5-SNAPSHOT.jar ./axis2-saaj-1.5-SNAPSHOT.jar ./mex-1.5-SNAPSHOT-impl.jar ./rampart-core-SNAPSHOT.jar ./rampart-policy-SNAPSHOT.jar ./rampart-trust-SNAPSHOT.jar ./synapse-core-SNAPSHOT.jar ./synapse-extensions-SNAPSHOT.jar ./synapse-samples-SNAPSHOT.jar ./synapse-transports-SNAPSHOT.jar ./wss4j-SNAPSHOT.jar ./axis2-transport-base-1.0-SNAPSHOT.jar ./axis2-transport-http-1.0-SNAPSHOT.jar ./axis2-transport-jms-1.0-SNAPSHOT.jar ./axis2-transport-mail-1.0-SNAPSHOT.jar ./sandesha2-core-SNAPSHOT.jar ./synapse-experimental-SNAPSHOT.jar ./synapse-tasks-SNAPSHOT.jar ./synapse-utils-SNAPSHOT.jar Removed from 1.2 release ./annogen-0.1.0.jar ./backport-util-concurrent-2.2.jar ./axis2-adb-codegen-1.4.jar ./axis2-java2wsdl-1.4.jar ./axis2-saaj-api-1.4.jar ./axis2-xmlbeans-1.4.jar ./mercury-core-0.91.jar ./mockobjects-core-0.09.jar ./mockobjects-jdk1.4-j2ee1.3-0.09.jar ./spring-xml-1.0.3.jar ./truezip-6.6.jar Upgraded from 1.2 release ./axiom-api-1.2.8.jar ./axiom-dom-1.2.8.jar ./axiom-impl-1.2.8.jar ./axis2-adb-1.5-SNAPSHOT.jar ./axis2-clustering-1.5-SNAPSHOT.jar ./axis2-codegen-SNAPSHOT.jar ./axis2-kernel-1.5-SNAPSHOT.jar ./axis2-mtompolicy-1.5-SNAPSHOT.jar ./axis2-saaj-1.5-SNAPSHOT.jar ./bcprov-jdk15-140.jar ./commons-codec-1.2.jar ./commons-collections-3.2.1.jar ./commons-lang-2.4.jar ./commons-logging-1.1.1.jar ./endorsed/xml-apis-1.3.04.jar ./geronimo-jms_1.1_spec-1.1.jar ./groovy-all-1.1-rc-1.jar ./httpcore-4.0.jar ./httpcore-nio-4.0.jar ./juli-6.0.16.jar ./log4j-1.2.15.jar ./mex-1.5-SNAPSHOT-impl.jar ./rampart-core-SNAPSHOT.jar ./rampart-policy-SNAPSHOT.jar ./rampart-trust-SNAPSHOT.jar ./synapse-core-SNAPSHOT.jar ./synapse-extensions-SNAPSHOT.jar ./synapse-samples-SNAPSHOT.jar ./synapse-transports-SNAPSHOT.jar ./tribes-6.0.16.jar ./wso2caching-core-3.0.jar ./wss4j-SNAPSHOT.jar ./xalan-2.7.1.jar ./XmlSchema-1.4.3.jar ./xmlsec-1.4.2.jar Added new for 1.3 release ./axis2-transport-base-1.0-SNAPSHOT.jar ./axis2-transport-http-1.0-SNAPSHOT.jar ./axis2-transport-jms-1.0-SNAPSHOT.jar ./axis2-transport-mail-1.0-SNAPSHOT.jar ./commons-cli-1.0.jar ./geronimo-activation_1.1_spec-1.0.1.jar ./geronimo-javamail_1.4_spec-1.2.jar ./geronimo-jta_1.0.1B_spec-1.0.jar ./geronimo-jta_1.1_spec-1.1.jar ./geronimo-saaj_1.3_spec-1.0.1.jar ./geronimo-ws-metadata_2.0_spec-1.1.2.jar ./jline-0.9.94.jar ./jruby-complete-0.9.9.jar ./sandesha2-core-SNAPSHOT.jar ./serializer-2.7.1.jar ./slf4j-log4j12-1.5.6.jar ./synapse-experimental-SNAPSHOT.jar ./synapse-tasks-SNAPSHOT.jar ./synapse-utils-SNAPSHOT.jar ./wso2eventing-api-20090401.110552-3.jar ./patches/httpcore-nio-4.0-patch-httpcore-193.jar Unchanged from 1.2 release to 1.3 ./activation-1.1.jar ./bcel-5.2.jar ./bsf-all-3.0-beta2.jar ./commons-dbcp-1.2.2.jar ./commons-fileupload-1.2.jar ./commons-httpclient-3.1.jar ./commons-io-1.4.jar ./commons-net-1.4.1.jar ./commons-pool-1.3.jar ./commons-vfs-1.1-587797.jar ./endorsed/xercesImpl-2.8.1.jar ./geronimo-stax-api_1.0_spec-1.0.1.jar ./jakarta-regexp-1.4.jar ./java-cup-0.0.jar ./jaxen-1.1.1.jar ./JLex-0.0.jar ./js-1.6R5.jar ./jsch-0.1.31.jar ./mail-1.4.jar ./neethi-2.0.4.jar ./opensaml-1.1.jar ./oro-2.0.8.jar ./quartz-1.6.0.jar ./saxon-8.9.jar ./saxon-dom-8.9.jar ./saxon-xqj-8.9.jar ./spring-aop-1.2.8.jar ./spring-beans-1.2.8.jar ./spring-context-1.2.8.jar ./spring-core-1.2.8.jar ./stax-api-1.0.1.jar ./woden-api-1.0M8.jar ./woden-impl-dom-1.0M8.jar ./wrapper-3.2.3.jar ./wsdl4j-1.6.2.jar ./wso2throttle-core-1.6.jar ./wstx-asl-3.2.4.jar ./xbean-2.2.0.jar ./xmlParserAPIs-2.6.0.jar ./xmlunit-1.1.jar -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: VFS Text Files with spaces don't work.
In theory you are correct but we have been a Web Service B2B shop for about 10 years and nothing can be assumed to work according to standards. We know that unless such elements are wrapped in CDATA the white space will get removed somewhere. Opinions on the net: Now when the XML specification says any white space, they donât really mean it. HA! The standards leave some aspects of white space handling up to the implementers, or at least thatâs what the implementers would have us believe. I suspect some implementers choose to ignore parts of the standards they donât like or canât accommodate easily in their toolsets. Itâs inevitable that different XML parsers make different interpretations of the standards. This leads to some fuzzy behavior where white space is concerned. another openxml rfp: White space handling is an unresolved issue in the present definition of XML parsers, falling outside the scope of both the DOM specification and the SAX API. In our case when we send data on to customer who knows what parser/technology gets used. How many other routers, mediators, proxies, mess up the XML; using technology from 1980's. So, in practise, we wrap all text data with leading/trailing spaces with CDATA . At the moment for these small files, using this data format standard, I am using a JS mediator to take the text payload and insert it into destination XML. This means using CDATA to wrap the JS script.. but then I can't add in another nested CDATA in the JS script XML to wrap the data. So I will have to move this to XSLT or most likely Java. Unless you know a way around this. Unfortunately due to size/volume of files we cannot log them directly in synapse. Due to privacy laws in US I cannot see the production data directly. so it takes a while to debug these issues. I trust you, that you believe, it cannot be happening inside Synapse/Axis and that really helps rule out where this is happening. But we are loosing the spaces; and the first place to rule out when tracing the files through the process was Synapse at VFS. Given these problems, wrapping the data at the start of the process with CDATA, although a paranoid approach, would mean it is then safe all the way through. Will take a few days to debug this here; tell you what we find. Thanks Kim -Original Message- From: Andreas Veithen [mailto:andreas.veit...@gmail.com] Sent: Fri 03/04/2009 19:00 To: dev@synapse.apache.org Subject: Re: VFS Text Files with spaces don't work. This is not very convincing for several reasons: * An XML parser never removes whitespace. * A validating XML parser reports whitespace _between elements_ in a special way, but it is up to the application to decide what to do with it. Note that we are not talking about this type of whitespace here. * XSLT is not schema aware. * While space=preserve is defined in the XML specs it has no well defined semantics and it is up to the application to interpret it. * Axis2 and Synapse don't (or at least shouldn't) remove any whitespace. What you really need to do is to determine at what step in the mediation the whitespace is lost. Then we can try to understand why this is so. Andreas On Fri, Apr 3, 2009 at 07:19, kimhorn kim.h...@icsglobal.net wrote: You are probably right. Haven't had time to look but I hope the payload text element is defined as space=preserve. If yes then its OK, If not then ? Any idea where is the �XSD is easily available ? It is probably one of the mediators removing the white space along the way; as XML does not preserve this. I will have to add in yet again more java to wrap the text field in CDATA . As the recipient cannot change their XSD, this looks like the only optionNot sure XSLT will work unless target name space also defines the element as space preserve ? My simple Synapse script is becoming a massive Java program. And I thought wouldn't it be easy to use a scripting tool like Synapse compared to writing Java code . How wrong. Thanks Kim Andreas Veithen-2 wrote: Are you sure that these spaces get trimmed inside the VFS transport and not somewhere in your mediation? Normally the plain text message builder is designed to strictly preserve the file content (including spaces), so this would be a serious bug. Andreas On Thu, Apr 2, 2009 at 08:52, kimhorn kim.h...@icsglobal.net wrote: Run into a problem with VFS reading text files with fixed field length fields, where empty fields are padded with spaces. There are a number of B2B formats that do this. If the empty fields are at the start or end of the file then when these are inserted into XML as Payload the XML removes the spaces. The text should be wrapped in CDATA with double Quotes to preserve this space data; but VFS does not do this. So the fields at start or end of file get lost and hence the whole file is now garbage. Hopefully reading them as binary files (not plan text) will get over this
Re: Synapse dependencies for 1.3
./spring-xml-1.0.3.jar This also is required I guess, I think we are using some utility methods from the spring-xml No, this one is no longer required. The corresponding dependency has been removed quite some time ago. Andreas - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
