Re: JMX notifications for Endpoint state changes

2009-12-04 Thread indika kumara 
What about if we add some configuration section (as a child node in
the configuration) that can be used by any mediator, endpoint, proxy
service, etc.


statistics policy 
trace policy 
monitoring policy 
reporting policy 
   ……


This might be useful in long-term if someone is going to develop tools
for monitoring, deluging, reporting etc.  for synapse .

Thanks
Indika

On Fri, Dec 4, 2009 at 12:47 PM, Supun Kamburugamuva  wrote:
> I was not thinking about the implementation. But since this is introducing a
> new configuration, I was bit concerned.
>
> Supun..
>
> On Thu, Dec 3, 2009 at 10:07 PM, Ruwan Linton 
> wrote:
>>
>> Supun, It is not going to be a that big change, you just need to change
>> the implementation of isStatisticsEnabled and isTracingEnabled method to
>> look for the global flag if it is not set at the respective component.
>>
>> and you need to modify the synapse configuration builder to look at the
>> definitions tag and set the global values of these.
>>
>> Thanks,
>> Ruwan
>>
>> On Fri, Dec 4, 2009 at 9:42 AM, Supun Kamburugamuva 
>> wrote:
>>>
>>> Hi Ruwan,
>>>
>>> I think if we do this the correct way, the way you've suggested is the
>>> correct way. I was bit reluctant to do that because it is kind of like a big
>>> change. At least at the conceptual level.
>>>
>>> I like your idea and I'll come up with an implementation.
>>>
>>> Eric, What do you think?
>>>
>>> Thanks,
>>> Supun..
>>>
>>> On Thu, Dec 3, 2009 at 6:21 PM, Ruwan Linton 
>>> wrote:

 Supun,

 I see a real value of Eric's suggestion. We could introduce three
 attributes called "statistics", "trace", and "notifications" in to the
 definitions tag level, so those are the global values and you may override
 the global value at any configurable node, like on a sequence or endpoint 
 or
 even on a proxy.

 It is not clean if we bring this into the properties file, the XML model
 that we use as the main configuration language allows you to nicely
 implement that. So this effects statistics collection and tracing as well,
 which can be turned on and off at a global level instead for the
 notifications.

 Thanks,
 Ruwan

 On Fri, Dec 4, 2009 at 4:54 AM, Supun Kamburugamuva 
 wrote:
>
> +1 for a global property and we can include it to the
> synapse.properties file easily. But I'm also not sure about introducing an
> attribute to the endpoint configuration.
>
> Thanks,
> Supun..
>
> On Fri, Dec 4, 2009 at 2:30 AM, Hubert, Eric
>  wrote:
>>
>> Agreed, coupling statistics and notification would not be a good idea
>> as we are talking about two non-related things.
>>
>>
>>
>> Regarding useful configurations options I would also need to think a
>> bit more about it…
>>
>> Introducing an optional attribute on the endpoint level to turn the
>> feature selectively on/off might (depending on the default) force the 
>> user
>> having to set it on a large number of configuration items.
>>
>> Having a global switch (either on or off) plus the ability to override
>> the global option on the endpoint level may save configuration overhead 
>> and
>> turn out to be more flexible, but could also make the configuration 
>> harder
>> to read/understand.
>>
>>
>>
>> Regards,
>>
>>    Eric
>>
>>
>>
>>
>>
>>
>>
>> 
>>
>> From: Supun Kamburugamuva [mailto:supu...@gmail.com]
>> Sent: Thursday, December 03, 2009 9:17 PM
>> To: dev@synapse.apache.org
>> Sub
>> ject: Re: JMX notifications for Endpoint state changes
>>
>>
>>
>> HI Eric,
>>
>> I can understand your suggestion about turning notifications on/off
>> selectively. One thing is if the statistics are enabled for a endpoint 
>> then
>> enable the notifications. But statistics and notifications are two 
>> different
>> things. So that may be not good. Any ideas from the community how to do
>> this? May be we can introduce an attribute to the endpoint configuration?
>>
>> Thanks,
>> Supun..
>>
>> On Fri, Dec 4, 2009 at 1:33 AM, Hubert, Eric
>>  wrote:
>>
>> Hi Supun,
>>
>>
>>
>> You are welcome! Regarding my second point I think you are still able
>> to deliver some details, if you really like. If I remember correctly 
>> there
>> are actually three attributes type, message and userData, type and 
>> message
>> being String and type being Object. So you can still use userData to add
>> more detail which should not go into the message. The only thing is that 
>> the
>> type of the user data should be some standard Object and not some custom
>> type. It has been a while since I last looked into this, but you may at
>> least want to check t

RE: JMX notifications for Endpoint state changes

2009-12-04 Thread Hubert, Eric 
Well, actually I thought in the same direction as Ruwan. If introducing a 
global configuration option it should be consistent with the other 
configurations like tracing and statistics. This was one point against adding 
this only for any newly introduced feature like JMX notifications. If we would 
like to use such a configuration option, than we should consistently support 
this also for statistics and tracing.


Hi Ruwan,

I think if we do this the correct way, the way you've suggested is the correct 
way. I was bit reluctant to do that because it is kind of like a big change. At 
least at the conceptual level.

I like your idea and I'll come up with an implementation.

Eric, What do you think?

RE: JMX notifications for Endpoint state changes

2009-12-04 Thread Hubert, Eric 

> From: indika kumara [mailto:indika.k...@gmail.com]
> Sent: Friday, December 04, 2009 9:37 AM

> 
> statistics policy 
> trace policy 
> monitoring policy 
> reporting policy 
>……
> 

To me a grouping makes absolutely sense. This would also be beneficial to have 
at the global level below definitions. I don't think that adding more and more 
"aspects" directly on the top level would be a good option. So yes, I like this 
idea...

Regards,
  Eric

Re: JMX notifications for Endpoint state changes

2009-12-04 Thread Ruwan Linton 
+1, we should go for this, and I think it will be very useful in a
production set up; if anything goes wrong and the admin wants to enable
tracing for the full synapse config he do not have to go onto each and every
config bit. OTOH, if he knows where the issue is he can just enable tracing
of that proxy only.

Thnaks,
Ruwan

On Fri, Dec 4, 2009 at 2:14 PM, Hubert, Eric wrote:

>  Well, actually I thought in the same direction as Ruwan. If introducing a
> global configuration option it should be consistent with the other
> configurations like tracing and statistics. This was one point against
> adding this only for any newly introduced feature like JMX notifications. If
> we would like to use such a configuration option, than we should
> consistently support this also for statistics and tracing.
>
>
>   --
>
> Hi Ruwan,
>
> I think if we do this the correct way, the way you've suggested is the
> correct way. I was bit reluctant to do that because it is kind of like a
> big change. At least at the conceptual level.
>
> I like your idea and I'll come up with an implementation.
>
> Eric, What do you think?
>
>


-- 
Ruwan Linton
Technical Lead & 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

Hudson build is still unstable: Synapse - 1.3 - SNAPSH OT » Apache Synapse - Non-blocking HTTP/s Transport #85

2009-12-04 Thread Apache Hudson Server 
See 




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

Build failed in Hudson: Synapse - 1.3 - SNA PSHOT » Apache Synapse - PIPE Transport #85

2009-12-04 Thread Apache Hudson Server 
See 


--
[INFO] 
[INFO] Building Apache Synapse - PIPE Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to 

[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-pipe-transport/builds/2009-12-04_12-02-31/archive/org.apache.synapse/synapse-pipe-transport/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

:[107,28]
 
receive(java.net.SocketAddress,org.apache.axis2.transport.base.datagram.DatagramEndpoint,byte[],int)
 in org.apache.axis2.transport.base.datagram.DatagramDispatcherCallback cannot 
be applied to (org.apache.synapse.transport.pipe.PipeEndpoint,byte[],int)


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 12 minutes 3 seconds
[INFO] Finished at: Fri Dec 04 12:14:50 UTC 2009
[INFO] Final Memory: 40M/191M
[INFO] 
Waiting for Hudson to finish collecting data


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

Build failed in Hudson: Synapse - 1.3 - SNAPSHOT #85

2009-12-04 Thread Apache Hudson Server 
See 


--
[...truncated 54 lines...]
[INFO] snapshot org.apache.sandesha2:sandesha2-parent:SNAPSHOT: checking for 
updates from wso2-m2
11K downloaded
[INFO] snapshot org.apache.axis2:addressing:SNAPSHOT: checking for updates from 
apache-snapshots
[INFO] snapshot org.apache.axis2:addressing:SNAPSHOT: checking for updates from 
wso2-m2
Downloading: 
http://repository.apache.org/snapshots/java-cup/java-cup/0.0/java-cup-0.0.pom
Downloading: http://dist.wso2.org/maven2//java-cup/java-cup/0.0/java-cup-0.0.pom
Downloading: 
http://people.apache.org/~asankha/repository/java-cup/java-cup/0.0/java-cup-0.0.pom
Downloading: 
http://repo1.maven.org/maven2/java-cup/java-cup/0.0/java-cup-0.0.pom
Downloading: http://repository.apache.org/snapshots/JLex/JLex/0.0/JLex-0.0.pom
Downloading: http://dist.wso2.org/maven2//JLex/JLex/0.0/JLex-0.0.pom
Downloading: 
http://people.apache.org/~asankha/repository/JLex/JLex/0.0/JLex-0.0.pom
Downloading: http://repo1.maven.org/maven2/JLex/JLex/0.0/JLex-0.0.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: http://dist.wso2.org/maven2//net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: http://repo1.maven.org/maven2/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://dist.wso2.org/maven2//net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://repo1.maven.org/maven2/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://dist.wso2.org/maven2//net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://repo1.maven.org/maven2/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
365K downloaded
[INFO] [compiler:compile]
Compiling 77 source files to 

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to 

[INFO] [surefire:test]
[INFO] Surefire report directory: 


---
 T E S T S
---
Running org.apache.synapse.util.TemporaryDataTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.434 sec

Results :

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

[HUDSON] Recording test results
[INFO] [bundle:bundle]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] [bundle:install]
[INFO] Parsing file:/export/home/hudson/.m2/repository/repository.xml
[INFO] Installing 
org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] Writing OBR metadata
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-04_12-02-31/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/pom.xml
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-04_12-02-31/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] 
[INFO] Building Apache Synapse - Transports
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-

Build failed in Hudson: Synapse - 1.3 - SNA PSHOT » Apache Synapse - PIPE Transport #86

2009-12-04 Thread Apache Hudson Server 
See 


--
[INFO] 
[INFO] Building Apache Synapse - PIPE Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to 

[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-pipe-transport/builds/2009-12-04_18-01-43/archive/org.apache.synapse/synapse-pipe-transport/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

:[107,28]
 
receive(java.net.SocketAddress,org.apache.axis2.transport.base.datagram.DatagramEndpoint,byte[],int)
 in org.apache.axis2.transport.base.datagram.DatagramDispatcherCallback cannot 
be applied to (org.apache.synapse.transport.pipe.PipeEndpoint,byte[],int)


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 3 minutes 8 seconds
[INFO] Finished at: Fri Dec 04 18:04:59 UTC 2009
[INFO] Final Memory: 39M/194M
[INFO] 


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

Hudson build is still unstable: Synapse - 1.3 - SNAPSH OT » Apache Synapse - Non-blocking HTTP/s Transport #86

2009-12-04 Thread Apache Hudson Server 
See 




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

Build failed in Hudson: Synapse - 1.3 - SNAPSHOT #86

2009-12-04 Thread Apache Hudson Server 
See 


--
[...truncated 384 lines...]
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-1] AxisEngine The service cannot be found for the 
endpoint reference (EPR) 
/services/TestService-637a9a2f-70be-4651-b637-332a4ed7b194
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-637a9a2f-70be-4651-b637-332a4ed7b194
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-1] ServerWorker Error processing POST request 
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-637a9a2f-70be-4651-b637-332a4ed7b194
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-2] AxisEngine The service cannot be found for the 
endpoint reference (EPR) 
/services/TestService-637a9a2f-70be-4651-b637-332a4ed7b194
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-637a9a2f-70be-4651-b637-332a4ed7b194
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-2] ServerWorker Error processing POST request 
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-637a9a2f-70be-4651-b637-332a4ed7b194
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.

Re: JMX notifications for Endpoint state changes

2009-12-04 Thread Supun Kamburugamuva 
+1 from me as well to the new aspect configuration. This solves the problem
more cleanly.

I'm not clear about one thing. Shall we make this aspect configuration to be
a child of other elements like mediators and endpoints or is it a top level
configuration only?

Thanks,
Supun..

On Fri, Dec 4, 2009 at 2:23 PM, Ruwan Linton  wrote:

> +1, we should go for this, and I think it will be very useful in a
> production set up; if anything goes wrong and the admin wants to enable
> tracing for the full synapse config he do not have to go onto each and every
> config bit. OTOH, if he knows where the issue is he can just enable tracing
> of that proxy only.
>
> Thnaks,
> Ruwan
>
>
> On Fri, Dec 4, 2009 at 2:14 PM, Hubert, Eric wrote:
>
>>  Well, actually I thought in the same direction as Ruwan. If introducing
>> a global configuration option it should be consistent with the other
>> configurations like tracing and statistics. This was one point against
>> adding this only for any newly introduced feature like JMX notifications. If
>> we would like to use such a configuration option, than we should
>> consistently support this also for statistics and tracing.
>>
>>
>>   --
>>
>> Hi Ruwan,
>>
>> I think if we do this the correct way, the way you've suggested is the
>> correct way. I was bit reluctant to do that because it is kind of like a
>> big change. At least at the conceptual level.
>>
>> I like your idea and I'll come up with an implementation.
>>
>> Eric, What do you think?
>>
>>
>
>
> --
> Ruwan Linton
> Technical Lead & 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
>



-- 
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

Re: JMX notifications for Endpoint state changes

2009-12-04 Thread Supun Kamburugamuva 
How about having following policies

ALL : no matter what is the configuration at the mediator or endpoint level
this aspect will be enabled for all the components, to further configure we
can define what is mean by all, for example all the endpoints but not
mediators or we can have a named list containing the names of the items we
need to turn this on.

NONE : no matter what is the configuration at the mediator or endpoint
level, this aspect will be disabled for all the component. as in ALL case we
can define what is meant by NONE

DEFAULT : default means the configurations at the endpoint or mediator level
will take effect

These are my initial thoughts.

Thanks,
Supun..

On Sat, Dec 5, 2009 at 12:44 AM, Supun Kamburugamuva wrote:

> +1 from me as well to the new aspect configuration. This solves the problem
> more cleanly.
>
> I'm not clear about one thing. Shall we make this aspect configuration to
> be a child of other elements like mediators and endpoints or is it a top
> level configuration only?
>
> Thanks,
> Supun..
>
>
> On Fri, Dec 4, 2009 at 2:23 PM, Ruwan Linton wrote:
>
>> +1, we should go for this, and I think it will be very useful in a
>> production set up; if anything goes wrong and the admin wants to enable
>> tracing for the full synapse config he do not have to go onto each and every
>> config bit. OTOH, if he knows where the issue is he can just enable tracing
>> of that proxy only.
>>
>> Thnaks,
>> Ruwan
>>
>>
>> On Fri, Dec 4, 2009 at 2:14 PM, Hubert, Eric 
>> wrote:
>>
>>>  Well, actually I thought in the same direction as Ruwan. If introducing
>>> a global configuration option it should be consistent with the other
>>> configurations like tracing and statistics. This was one point against
>>> adding this only for any newly introduced feature like JMX notifications. If
>>> we would like to use such a configuration option, than we should
>>> consistently support this also for statistics and tracing.
>>>
>>>
>>>   --
>>>
>>> Hi Ruwan,
>>>
>>> I think if we do this the correct way, the way you've suggested is the
>>> correct way. I was bit reluctant to do that because it is kind of like a
>>> big change. At least at the conceptual level.
>>>
>>> I like your idea and I'll come up with an implementation.
>>>
>>> Eric, What do you think?
>>>
>>>
>>
>>
>> --
>> Ruwan Linton
>> Technical Lead & 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
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>


-- 
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

RE: JMX notifications for Endpoint state changes

2009-12-04 Thread Hubert, Eric 
I would vote for both, on global and on those child elements where it is 
applicable with the simple rule, that at runtime the most specific one wins.

This would allow for the following scenarios.

Turn it off for all (globally)
Turn it off globally, but only activate it on demand for specific endpoints, 
services etc.
Turn it on globally
Turn it on globally, but disable it for some specific services, endpoints 
(exclusions)

Of cause you could also add a configuration right in the middle on the level of 
the services or endpoints etc., if someone also wants to turn an aspect only on 
for ALL services, but not for all endpoints, but just some of them.

Regards,
  Eric




From: Supun Kamburugamuva [mailto:supu...@gmail.com]
Sent: Friday, December 04, 2009 8:15 PM
To: dev@synapse.apache.org
Subject: Re: JMX notifications for Endpoint state changes

+1 from me as well to the new aspect configuration. This solves the problem 
more cleanly.

I'm not clear about one thing. Shall we make this aspect configuration to be a 
child of other elements like mediators and endpoints or is it a top level 
configuration only?

Thanks,
Supun..
On Fri, Dec 4, 2009 at 2:23 PM, Ruwan Linton 
mailto:ruwan.lin...@gmail.com>> wrote:
+1, we should go for this, and I think it will be very useful in a production 
set up; if anything goes wrong and the admin wants to enable tracing for the 
full synapse config he do not have to go onto each and every config bit. OTOH, 
if he knows where the issue is he can just enable tracing of that proxy only.

Thnaks,
Ruwan

On Fri, Dec 4, 2009 at 2:14 PM, Hubert, Eric 
mailto:eric.hub...@foxmobile.com>> wrote:
Well, actually I thought in the same direction as Ruwan. If introducing a 
global configuration option it should be consistent with the other 
configurations like tracing and statistics. This was one point against adding 
this only for any newly introduced feature like JMX notifications. If we would 
like to use such a configuration option, than we should consistently support 
this also for statistics and tracing.


Hi Ruwan,

I think if we do this the correct way, the way you've suggested is the correct 
way. I was bit reluctant to do that because it is kind of like a big change. At 
least at the conceptual level.

I like your idea and I'll come up with an implementation.

Eric, What do you think?


--
Ruwan Linton
Technical Lead & 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



--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

Re: JMX notifications for Endpoint state changes

2009-12-04 Thread Supun Kamburugamuva 
Hi,

If we can define the statistics enabled endpoints or mediators at the top
level aspect configuration we can leave the aspect configuration element
only to the top level. This reduce the clutter from the specific component
configurations. Specific component configurations can focus only on what
they are mean to do. Things like statistics collection can be separated from
the mediator configurations.

Thanks,
Supun..

On Sat, Dec 5, 2009 at 1:56 AM, Hubert, Eric wrote:

>  I would vote for both, on global and on those child elements where it is
> applicable with the simple rule, that at runtime the most specific one wins.
>
>
>
> This would allow for the following scenarios.
>
>
>
> Turn it off for all (globally)
>
> Turn it off globally, but only activate it on demand for specific
> endpoints, services etc.
>
> Turn it on globally
>
> Turn it on globally, but disable it for some specific services, endpoints
> (exclusions)
>
>
>
> Of cause you could also add a configuration right in the middle on the
> level of the services or endpoints etc., if someone also wants to turn an
> aspect only on for ALL services, but not for all endpoints, but just some of
> them.
>
>
>
> Regards,
>
>   Eric
>
>
>
>
>
>
>   --
>
> *From:* Supun Kamburugamuva [mailto:supu...@gmail.com]
> *Sent:* Friday, December 04, 2009 8:15 PM
>
> *To:* dev@synapse.apache.org
> *Subject:* Re: JMX notifications for Endpoint state changes
>
>
>
> +1 from me as well to the new aspect configuration. This solves the problem
> more cleanly.
>
> I'm not clear about one thing. Shall we make this aspect configuration to
> be a child of other elements like mediators and endpoints or is it a top
> level configuration only?
>
> Thanks,
> Supun..
>
> On Fri, Dec 4, 2009 at 2:23 PM, Ruwan Linton 
> wrote:
>
> +1, we should go for this, and I think it will be very useful in a
> production set up; if anything goes wrong and the admin wants to enable
> tracing for the full synapse config he do not have to go onto each and every
> config bit. OTOH, if he knows where the issue is he can just enable tracing
> of that proxy only.
>
> Thnaks,
> Ruwan
>
>
>
> On Fri, Dec 4, 2009 at 2:14 PM, Hubert, Eric 
> wrote:
>
> Well, actually I thought in the same direction as Ruwan. If introducing a
> global configuration option it should be consistent with the other
> configurations like tracing and statistics. This was one point against
> adding this only for any newly introduced feature like JMX notifications. If
> we would like to use such a configuration option, than we should
> consistently support this also for statistics and tracing.
>
>
>   --
>
> Hi Ruwan,
>
> I think if we do this the correct way, the way you've suggested is the
> correct way. I was bit reluctant to do that because it is kind of like a
> big change. At least at the conceptual level.
>
> I like your idea and I'll come up with an implementation.
>
> Eric, What do you think?
>
>
>
>--
> Ruwan Linton
> Technical Lead & 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
>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>


-- 
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com

Hudson build is still unstable: Synapse - 1.3 - SNAPSH OT » Apache Synapse - Non-blocking HTTP/s Transport #87

2009-12-04 Thread Apache Hudson Server 
See 




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

Build failed in Hudson: Synapse - 1.3 - SNA PSHOT » Apache Synapse - PIPE Transport #87

2009-12-04 Thread Apache Hudson Server 
See 


--
[INFO] 
[INFO] Building Apache Synapse - PIPE Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to 

[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-pipe-transport/builds/2009-12-05_00-25-30/archive/org.apache.synapse/synapse-pipe-transport/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

:[107,28]
 
receive(java.net.SocketAddress,org.apache.axis2.transport.base.datagram.DatagramEndpoint,byte[],int)
 in org.apache.axis2.transport.base.datagram.DatagramDispatcherCallback cannot 
be applied to (org.apache.synapse.transport.pipe.PipeEndpoint,byte[],int)


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 4 minutes 54 seconds
[INFO] Finished at: Sat Dec 05 00:30:34 UTC 2009
[INFO] Final Memory: 40M/194M
[INFO] 


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

Build failed in Hudson: Synapse - 1.3 - SNAPSHOT #87

2009-12-04 Thread Apache Hudson Server 
See 


--
[...truncated 71 lines...]
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: http://dist.wso2.org/maven2//net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: http://repo1.maven.org/maven2/net/sf/saxon/saxon/8.9/saxon-8.9.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://dist.wso2.org/maven2//net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://repo1.maven.org/maven2/net/sf/saxon/saxon-dom/8.9/saxon-dom-8.9.pom
Downloading: 
http://repository.apache.org/snapshots/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://dist.wso2.org/maven2//net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://people.apache.org/~asankha/repository/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
Downloading: 
http://repo1.maven.org/maven2/net/sf/saxon/saxon-xqj/8.9/saxon-xqj-8.9.pom
365K downloaded
[INFO] [compiler:compile]
Compiling 77 source files to 

[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to 

[INFO] [surefire:test]
[INFO] Surefire report directory: 


---
 T E S T S
---
Running org.apache.synapse.util.TemporaryDataTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.712 sec

Results :

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0

[HUDSON] Recording test results
[INFO] [bundle:bundle]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] [bundle:install]
[INFO] Parsing file:/export/home/hudson/.m2/repository/repository.xml
[INFO] Installing 
org/apache/synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] Writing OBR metadata
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-05_00-25-30/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/pom.xml
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-commons/builds/2009-12-05_00-25-30/archive/org.apache.synapse/synapse-commons/1.3.0-SNAPSHOT/synapse-commons-1.3.0-SNAPSHOT.jar
[INFO] 
[INFO] Building Apache Synapse - Transports
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing 

 to 
/export/home/hudson/.m2/repository/org/apache/synapse/synapse-transports/1.3.0-SNAPSHOT/synapse-transports-1.3.0-SNAPSHOT.pom
[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-transports/builds/2009-12-05_00-25-30/archive/org.apache.synapse/synapse-transports/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[INFO] Building Apache Synapse - Non-blocking HTTP/s Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] snapshot org.apache.axis2:axis2

Re: JMX notifications for Endpoint state changes

2009-12-04 Thread Ruwan Linton 
Hhhmmm, not sure whether it is good to keep a one global aspect
configuration which configures all the child nodes even when you need to
turn on statistics (for example) for a given sequence, that will make the
configuration readability harder. I would think of the implementation when
deciding the configuration design, so that it is not affecting the
performance as well.

I would like to keep a global configuration of aspects, yes as Supun
explined that can define whether all services, all endpoints or
sequences but not a named entity. The default behaviour will be at
global level all these will be turned off for all types of entities.

Then at each and every element level you can define there aspects using the
same configuraiton.

Alternately, we could let the aspect configurations to be refered from from
all the elements, inorder to make this work we need to be able to define a
named set of aspects and from services and sequences they can refer to its
aspect. It will enable us to reuse the aspect configuraitons of the same
type within different elements without redefining.

Being said all that I would like to do the initial implementation of this,
considering the amount of change that this idea is going to take us.

Thanks,
Ruwan

On Sat, Dec 5, 2009 at 2:04 AM, Supun Kamburugamuva wrote:

> Hi,
>
> If we can define the statistics enabled endpoints or mediators at the top
> level aspect configuration we can leave the aspect configuration element
> only to the top level. This reduce the clutter from the specific component
> configurations. Specific component configurations can focus only on what
> they are mean to do. Things like statistics collection can be separated from
> the mediator configurations.
>
> Thanks,
> Supun..
>
>
> On Sat, Dec 5, 2009 at 1:56 AM, Hubert, Eric wrote:
>
>>  I would vote for both, on global and on those child elements where it is
>> applicable with the simple rule, that at runtime the most specific one wins.
>>
>>
>>
>> This would allow for the following scenarios.
>>
>>
>>
>> Turn it off for all (globally)
>>
>> Turn it off globally, but only activate it on demand for specific
>> endpoints, services etc.
>>
>> Turn it on globally
>>
>> Turn it on globally, but disable it for some specific services, endpoints
>> (exclusions)
>>
>>
>>
>> Of cause you could also add a configuration right in the middle on the
>> level of the services or endpoints etc., if someone also wants to turn an
>> aspect only on for ALL services, but not for all endpoints, but just some of
>> them.
>>
>>
>>
>> Regards,
>>
>>   Eric
>>
>>
>>
>>
>>
>>
>>   --
>>
>> *From:* Supun Kamburugamuva [mailto:supu...@gmail.com]
>> *Sent:* Friday, December 04, 2009 8:15 PM
>>
>> *To:* dev@synapse.apache.org
>> *Subject:* Re: JMX notifications for Endpoint state changes
>>
>>
>>
>> +1 from me as well to the new aspect configuration. This solves the
>> problem more cleanly.
>>
>> I'm not clear about one thing. Shall we make this aspect configuration to
>> be a child of other elements like mediators and endpoints or is it a top
>> level configuration only?
>>
>> Thanks,
>> Supun..
>>
>> On Fri, Dec 4, 2009 at 2:23 PM, Ruwan Linton 
>> wrote:
>>
>> +1, we should go for this, and I think it will be very useful in a
>> production set up; if anything goes wrong and the admin wants to enable
>> tracing for the full synapse config he do not have to go onto each and every
>> config bit. OTOH, if he knows where the issue is he can just enable tracing
>> of that proxy only.
>>
>> Thnaks,
>> Ruwan
>>
>>
>>
>> On Fri, Dec 4, 2009 at 2:14 PM, Hubert, Eric 
>> wrote:
>>
>> Well, actually I thought in the same direction as Ruwan. If introducing a
>> global configuration option it should be consistent with the other
>> configurations like tracing and statistics. This was one point against
>> adding this only for any newly introduced feature like JMX notifications. If
>> we would like to use such a configuration option, than we should
>> consistently support this also for statistics and tracing.
>>
>>
>>   --
>>
>> Hi Ruwan,
>>
>> I think if we do this the correct way, the way you've suggested is the
>> correct way. I was bit reluctant to do that because it is kind of like a
>> big change. At least at the conceptual level.
>>
>> I like your idea and I'll come up with an implementation.
>>
>> Eric, What do you think?
>>
>>
>>
>>--
>> Ruwan Linton
>> Technical Lead & 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
>>
>>
>>
>>
>> --
>> Software Engineer, WSO2 Inc
>> http://wso2.org
>> supunk.blogspot.com
>>
>>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>


-- 
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ru

Hudson build is still unstable: Synapse - 1.3 - SNAPSH OT » Apache Synapse - Non-blocking HTTP/s Transport #88

2009-12-04 Thread Apache Hudson Server 
See 




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

Build failed in Hudson: Synapse - 1.3 - SNA PSHOT » Apache Synapse - PIPE Transport #88

2009-12-04 Thread Apache Hudson Server 
See 


--
[INFO] 
[INFO] Building Apache Synapse - PIPE Transport
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean]
[INFO] Deleting directory 

[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 9 source files to 

[HUDSON] Archiving 

 to /export/home/hudson/hudson/jobs/Synapse - 1.3 - 
SNAPSHOT/modules/org.apache.synapse$synapse-pipe-transport/builds/2009-12-05_06-01-52/archive/org.apache.synapse/synapse-pipe-transport/1.3.0-SNAPSHOT/pom.xml
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

:[107,28]
 
receive(java.net.SocketAddress,org.apache.axis2.transport.base.datagram.DatagramEndpoint,byte[],int)
 in org.apache.axis2.transport.base.datagram.DatagramDispatcherCallback cannot 
be applied to (org.apache.synapse.transport.pipe.PipeEndpoint,byte[],int)


[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 3 minutes 51 seconds
[INFO] Finished at: Sat Dec 05 06:06:03 UTC 2009
[INFO] Final Memory: 39M/152M
[INFO] 


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

Build failed in Hudson: Synapse - 1.3 - SNAPSHOT #88

2009-12-04 Thread Apache Hudson Server 
See 


--
[...truncated 331 lines...]
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-17] AxisEngine The service cannot be found for the 
endpoint reference (EPR) 
/services/TestService-347c1d21-9d7a-4f24-ab77-7de9d9b64c62
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-347c1d21-9d7a-4f24-ab77-7de9d9b64c62
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-17] ServerWorker Error processing POST request 
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-347c1d21-9d7a-4f24-ab77-7de9d9b64c62
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-18] AxisEngine The service cannot be found for the 
endpoint reference (EPR) 
/services/TestService-347c1d21-9d7a-4f24-ab77-7de9d9b64c62
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-347c1d21-9d7a-4f24-ab77-7de9d9b64c62
at 
org.apache.axis2.engine.DispatchPhase.checkPostConditions(DispatchPhase.java:65)
at org.apache.axis2.engine.Phase.invoke(Phase.java:334)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:251)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:160)
at 
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at 
org.apache.synapse.transport.nhttp.ServerWorker.processEntityEnclosingMethod(ServerWorker.java:349)
at 
org.apache.synapse.transport.nhttp.ServerWorker.run(ServerWorker.java:241)
at 
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:58)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
ERROR [HttpServerWorker-18] ServerWorker Error processing POST request 
org.apache.axis2.AxisFault: The service cannot be found for the endpoint 
reference (EPR) /services/TestService-347c1d21-9d7a-4f24-ab77-7de9d9b64c62
at 
org.apache.axis2.engine.Disp