Asankha, I did some modifications to try to fix this. Can you test again?
Andreas On 15 sept. 08, at 15:17, Asankha C. Perera wrote:
Andreas Logs are attached asankha Andreas Veithen wrote:Asankha,The tests all work correctly on my machine. I will need your Surefire logs to figure out why they are failing on your machine.Andreas Quoting "Asankha C. Perera" <[EMAIL PROTECTED]>:I reverted by commit.. but still see failures: Tests in error:0001 :test = AsyncXML ,data = ASCII ,messageType = SOAP11 ,client = java .net ,endpoint = axis (org .apache .synapse.transport.testkit.tests.async.XMLAsyncMessageTestCase) 0034 :test = AsyncTextPlain ,data = ASCII ,client = java .net ,endpoint = axis (org.apache.synapse.transport.testkit.tests.async.TextPlainTestCase) 0035 :test = AsyncTextPlain ,data = UTF8 ,client = java .net ,endpoint = axis (org.apache.synapse.transport.testkit.tests.async.TextPlainTestCase) 0036 :test = AsyncTextPlain ,data = Latin1 ,client = java .net ,endpoint = axis (org.apache.synapse.transport.testkit.tests.async.TextPlainTestCase) 0043 :test = AsyncBinary ,client = java .net ,endpoint = axis (org.apache.synapse.transport.testkit.tests.async.BinaryTestCase) 0046 :test = REST ,client = java .net ,endpoint =axis(org.apache.synapse.transport.testkit.tests.async.RESTTestCase) 0143 :test = EchoXML ,data = ASCII ,messageType = POX ,broker = qpid ,replyDestType = queue ,destType = queue ,contentTypeMode = TRANSPORT ,client = axis ,endpoint = mock (org .apache .synapse .transport.testkit.tests.echo.XMLRequestResponseMessageTestCase)Andreas, can you fix these and checkin the changes asankha Asankha C. Perera wrote:RuwanI am reverting my changes as we speak, until such time I can fix them and make sure the tests run.. sorry for this..asankha Andreas Veithen wrote:For the test failures: On Friday, Asankha made a change in the mail transport that causes 12 unit tests to fail. In addition to that, some tests in the transports module may fail on some platforms/systems because of concurrency issues. They run fine on my machines (Mac OS X and Windows XP), but Asankha told me that he sees this kind of failures (should be corrected in the meantime).Andreas Quoting Ruwan Linton <[EMAIL PROTECTED]>:Sorry Paul, I was also unable to comment on your last queries.... as you may know I am traveling. I think the above 2 points that you made have some interesting value in it. Therefore I would like to keep the ability to configure the event source and the notification service sections in theconfiguration.As you told, I just started the implementation and you can expect the initial version soon. For that lets go with the proposed configuration and I will keep the two elements to configure the notification section andpublishing section.BTW: I am seeing a test failure in the trunk? Do any one know the reason forthis? Andreas? (PS: please make sure all tests are passing before commit) Thanks, RuwanOn Mon, Sep 15, 2008 at 4:02 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote:Any other comments on this? I know Ruwan is working on it and I knowwe would appreciate feedback and thoughts. Paul ---------- Forwarded message ---------- From: Paul Fremantle <[EMAIL PROTECTED]> Date: Fri, Sep 12, 2008 at 11:56 AM Subject: Re: Proposal to implement ws-eventing and an event distribution model in Synapse To: [email protected] Ruwan The reasons I think we should keep the WSEventing section are:1) We should support other models - WS-Notification, etc. Although we have started from Eventing, this is a fairly generic model of eventsand I think we should keep it layered. 2) You may need to configure security or other aspects onto the WSEventing endpoint, so you need to offer the same configuration elements that proxy does (except target). PaulOn Fri, Sep 12, 2008 at 10:01 AM, Ruwan Linton <[EMAIL PROTECTED] >wrote:Paul,Very nice explanation of the concepts that we have been trying to put together into the code. Let me add some more to your explanation andrefinethe configuration a bit more. <eventSource name="blah"> <subscriptionManagerclass = "org.apache.synapse.events.DefaultInMemorySubscriptionManager"><property name="blah">some xml prop</property> <property name="other" value="some text property"/> </subscriptionManager> <staticSubscriptions> <subscription id="static1"> <filter..../> <sequence.../> <endpoint../> </subscription>* <staticSubscriptions>? <eventSource/>Here I am getting rid of the wsEventing configuration element where you specify the subscription service and the event source service. Somy idea iswe can extend the proxy services model here and create a newEventingMessageReceiver, which listens for all the requests coming tothisevent source. (I must also say at this point event source is now aserviceinside synapse and that fits with the model of extending the proxyservicebehavior) This EventingMessageReceiver knows how to filter out the thesubscriptionmessages from the notification messages and it uses the specified subscription manager if it is a subscription request, and if it is anotification message this receiver will delegate the request tothe eventpublisher where you find the set of subscribers with matching filter conditions and execute the mediation sequence and then send the event tothespecified endpoint.Paul, what do you think about this implementation. I am halfway throughtheimplementation and can have a look at this in the weekend :-) I have attached an architecture diagram which explains this concept a littlemoreand that explains that the event source itself is now exposed as aserviceto which you can send subscriptions and notifications. Thanks, RuwanOn Fri, Sep 12, 2008 at 9:15 AM, Paul Fremantle <[EMAIL PROTECTED] >wrote:Ruwan, AsankaA and I have been building a POC using WS- Eventing this week and we think we have come up with a reasonable model. We've already iterated several times, and in writing it out I have iteratedbeyond what the three of us discussed, so I am expecting more iterations now.What we implemented is a mediator that distributes events based on afilter. The initial code was almost dead simple: for (Subscription subs : manager.getSubscribers()) { boolean response = subs.getFilterMediator().test(mc); if (response) {Endpoint ep = subs.getEndpoint(); ep.send(getClonedMessageContext(mc));} }As we implemented the POC it became clear that it was more elegant to be able to associate a sequence to a particular subscription, and execute that sequence before sending. This goes a bit beyond the standard WS-Eventing model, but doesn't seem to contradict it or be abad fit. We also implemented a WS-Eventing subscribe model. Now that islogically separate, because there might be other ways to subscribe. For example, you might subscribe by adding an entry in a registry or using WS-Notification or your own interface. We also have allowedsimple static subscriptions in the synapse.xml model too.So the mediator itself is really simple - it only needs to get access to some kind of thing that manages the subscriptions that can give it a list of subscribers. In WS-Eventing an "Event Source" is something that emits events. Effectively our mediator is therefore an event source. So effectively the event source name is how you reference themanager that gives you the list of subscribers: <sequence> <event-source-publisher event-source-name="name"/> </sequence>Now how do you define these event sources. Well we want a new top level child of <definitions> that is configured at start time. Andthis defines an event-source, and also configures how the subscriptions can happen. <definitions> <eventSource name="blah"> <subscriptionManagerclass = "org .apache.synapse.events.DefaultInMemorySubscriptionManager"><property name="blah">some xml prop</property> <property name="other" value="some text property"/> </subscriptionManager> <subscription id="static1"> <filter....> <sequence...> <endpoint..> </subscription> <subscription...> <wsEventing> <eventSourceService name="myEventSource"> <same subchildren of proxy go here> </eventSourceService> <subscriptionManagerService name="myEventSubManager"> <same subchildren of proxy go here> </subscriptionManager> </wsEventing> <eventSource> Lets go through this:Each event source has a subscription manager. This is a class that keeps track of subscriptions. Here are some examples: a transient in memory one. A database backed persistent one. A registry backed read-only one. A registry backed read-write one. The class mustimplement a simple interface: public interface SubscriptionManager { List<Subscription> getSubscribers(); Subscription getSubscription(String id); String addSubscription(Subscription subs); boolean deleteSubscription(String id); }The subscriptionManager instance is injected with config properties at startup just like other things are (tasks, class mediators, etc). These might contain the JDBC connection parameters or the URL of theregistry.Next come static subscriptions. These are added into the subscriptionmanager by synapse. That happens once at startup.The next piece is WSEventing specific, but there could be other children for notification etc. Here I'm not 100% sure that we need to separate the EventSourceService from the SubscriptionManagerService. In WS-Eventing it says these can be the same endpoint or different. Basically the configuration of these is the same as a proxy, allowingconfiguration of security etc for this endpoint.We certainly haven't done everything. We haven't handled expiry, though . We haven't thought about other deliveryModes. We haven't dealt with efficiently handling evaluating multiple subscriptions against a single message at once. We have simply re-used the existing filtermediator code to implement XPath and Xpath/Regex filters as is (we can be much more efficient, for Xpaths, by e.g. using DanD's SXC code which can evaluate multiple Xpaths on a single message). But itsnot a bad start.I'd really appreciate if we have the right overall structure. I did a first cut of code, but Ruwan is tidying it up right now, so expect acheck-in soon. Thanks Paul -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Asankha C. Perera WSO2 - http://wso2.org http://esbmagic.blogspot.com-- Asankha C. Perera WSO2 - http://wso2.org http://esbmagic.blogspot.com--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]-- Asankha C. Perera WSO2 - http://wso2.org http://esbmagic.blogspot.com<surefire- reports .zip >---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
