You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@synapse.apache.org by kbohnenberger <ke...@mantech.com> on 2009/04/03 18:16:23 UTC

Custom mediator with the snapshot build

I have a custom mediator that works fine with the 1.2 release, however with
the nighly build i can see it get deployed in the logs but the "mediate"
method never seems to get called.  A

Any ideas?

Keith
-- 
View this message in context: http://www.nabble.com/Custom-mediator-with-the-snapshot-build-tp22871716p22871716.html
Sent from the Synapse - User mailing list archive at Nabble.com.


Re: Custom mediator with the snapshot build

Posted by Ruwan Linton <ru...@gmail.com>.
On Sat, Apr 4, 2009 at 10:58 PM, Hubert, Eric <Er...@foxmobile.com>wrote:

>    The second option is to log a message by default if its sent to
> /soap/xxx on the console.. so that the user knows what went wrong..
>
>
> Of course +1 for this.
>
> I agree.. lets just do this now...
>
> This sounds to be the best option. What is send back to the client in case
> the context does not match? I’d assume currently nothing?
>

It gets dispatched for the message mediation.... basically goes to the main
sequence, a proper configuration should take care of sending faults inside
the main sequence within a filter.

May be we can improve the default main sequence to send a fault back to the
client if the request is not matching the current filter?

Thanks,
Ruwan

-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

RE: Custom mediator with the snapshot build

Posted by "Hubert, Eric" <Er...@foxmobile.com>.
	The second option is to log a message by default if its sent to
/soap/xxx on the console.. so that the user knows what went wrong..


Of course +1 for this.

I agree.. lets just do this now...

This sounds to be the best option. What is send back to the client in
case the context does not match? I'd assume currently nothing?


Re: Custom mediator with the snapshot build

Posted by "Asankha C. Perera" <as...@apache.org>.
>     The second option is to log a message by default if its sent to
>     /soap/xxx on the console.. so that the user knows what went wrong..
>
>
> Of course +1 for this.
I agree.. lets just do this now...

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com





Re: Custom mediator with the snapshot build

Posted by Ruwan Linton <ru...@gmail.com>.
On Sat, Apr 4, 2009 at 9:29 PM, Asankha C. Perera <as...@apache.org>wrote:

>  Hi Ruwan
>
> On Sat, Apr 4, 2009 at 9:00 PM, Asankha C. Perera <as...@apache.org>wrote:
>
>> Ruwan / Eric
>>
>> AFAIK, axis2 doesn't support this sort of a aliasing.
>>
>>  That may be true with Axis2, but since the NIO transport is still under
>> our control, we should be able to switch this internally special casing
>> this.. If someone raises a JIRA and no developers have objections, I think
>> this would be something good to do
>>
>
> Asankha,
>
> I am not sure I am in favor of this change.... it is going to be sort of a
> hard coded redirection, which cannot be eliminated if we do at the transport
> layer.  Well, if you implement this in a way that it can be configured via a
> parameter in the transport configuration I don't have any objection so that
> we can get rid of this redirection by commenting out that parameter, and we
> can map this to any other value if required as well.
>
> The axis2.xml has the following parameter that applies only for HTTP/s..
> Since this currently effectively allows only one context for all services,
> there will not be a conflict.. I mean all services would be under
> /services/xxx anyway.. so anything else would end up in the main sequence..
>
> <parameter name="servicePath">services</parameter>
>
> What if we overload the above as a comma separated list to say
> "services,soap" etc?.. I know its a hack.. and I will only do this if all of
> us think it would be good..
>

Hhhmmm :-(, I am still a bit negative on this change, this might mess up the
WSDL generation, what param value should we treat as the actual and what are
the aliases.... there is a bit of ambiguity there.


>
>
> The second option is to log a message by default if its sent to /soap/xxx
> on the console.. so that the user knows what went wrong..
>

Of course +1 for this.

Thanks,
Ruwan


>
>
> cheers
> asankha
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
> http://esbmagic.blogspot.com
>
>
>


-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Re: Custom mediator with the snapshot build

Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Ruwan
> On Sat, Apr 4, 2009 at 9:00 PM, Asankha C. Perera <asankha@apache.org 
> <ma...@apache.org>> wrote:
>
>     Ruwan / Eric
>
>>     AFAIK, axis2 doesn't support this sort of a aliasing.
>     That may be true with Axis2, but since the NIO transport is still
>     under our control, we should be able to switch this internally
>     special casing this.. If someone raises a JIRA and no developers
>     have objections, I think this would be something good to do
>
>
> Asankha,
>
> I am not sure I am in favor of this change.... it is going to be sort 
> of a hard coded redirection, which cannot be eliminated if we do at 
> the transport layer.  Well, if you implement this in a way that it can 
> be configured via a parameter in the transport configuration I don't 
> have any objection so that we can get rid of this redirection by 
> commenting out that parameter, and we can map this to any other value 
> if required as well.
The axis2.xml has the following parameter that applies only for HTTP/s.. 
Since this currently effectively allows only one context for all 
services, there will not be a conflict.. I mean all services would be 
under /services/xxx anyway.. so anything else would end up in the main 
sequence..

<parameter name="servicePath">services</parameter>

What if we overload the above as a comma separated list to say 
"services,soap" etc?.. I know its a hack.. and I will only do this if 
all of us think it would be good..

The second option is to log a message by default if its sent to 
/soap/xxx on the console.. so that the user knows what went wrong..

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com





Re: Custom mediator with the snapshot build

Posted by Ruwan Linton <ru...@gmail.com>.
On Sat, Apr 4, 2009 at 9:00 PM, Asankha C. Perera <as...@apache.org>wrote:

>  Ruwan / Eric
>
> AFAIK, axis2 doesn't support this sort of a aliasing.
>
> That may be true with Axis2, but since the NIO transport is still under our
> control, we should be able to switch this internally special casing this..
> If someone raises a JIRA and no developers have objections, I think this
> would be something good to do
>

Asankha,

I am not sure I am in favor of this change.... it is going to be sort of a
hard coded redirection, which cannot be eliminated if we do at the transport
layer.  Well, if you implement this in a way that it can be configured via a
parameter in the transport configuration I don't have any objection so that
we can get rid of this redirection by commenting out that parameter, and we
can map this to any other value if required as well.

Thanks,
Ruwan


>
>
> cheers
> asankha
>
> On Sat, Apr 4, 2009 at 1:04 AM, Hubert, Eric <Er...@foxmobile.com>wrote:
>
>>
>> Hi,
>>
>> although it is a quite trivial change from context name /soap to /services
>> we have seen a couple of problems/irritated users, so I asked myself whether
>> it wouldn't be easily possible to configure something in axis2.xml to use
>> /soap as an alias for /services.
>> This way we could document the change for 1.3 and declare /soap as
>> deprecated and remove it with the next major release.
>>
>>
>
> --
> Asankha C. Perera
> AdroitLogic, http://adroitlogic.org
> http://esbmagic.blogspot.com
>
>
>


-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Re: Custom mediator with the snapshot build

Posted by "Asankha C. Perera" <as...@apache.org>.
Ruwan / Eric
> AFAIK, axis2 doesn't support this sort of a aliasing.
That may be true with Axis2, but since the NIO transport is still under 
our control, we should be able to switch this internally special casing 
this.. If someone raises a JIRA and no developers have objections, I 
think this would be something good to do

cheers
asankha
> On Sat, Apr 4, 2009 at 1:04 AM, Hubert, Eric 
> <Eric.Hubert@foxmobile.com <ma...@foxmobile.com>> wrote:
>
>
>     Hi,
>
>     although it is a quite trivial change from context name /soap to
>     /services we have seen a couple of problems/irritated users, so I
>     asked myself whether it wouldn't be easily possible to configure
>     something in axis2.xml to use /soap as an alias for /services.
>     This way we could document the change for 1.3 and declare /soap as
>     deprecated and remove it with the next major release.
>


-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com





Re: Custom mediator with the snapshot build

Posted by Ruwan Linton <ru...@gmail.com>.
AFAIK, axis2 doesn't support this sort of a aliasing.

Thanks,
Ruwan

On Sat, Apr 4, 2009 at 1:04 AM, Hubert, Eric <Er...@foxmobile.com>wrote:

>
> Hi,
>
> although it is a quite trivial change from context name /soap to /services
> we have seen a couple of problems/irritated users, so I asked myself whether
> it wouldn't be easily possible to configure something in axis2.xml to use
> /soap as an alias for /services.
> This way we could document the change for 1.3 and declare /soap as
> deprecated and remove it with the next major release.
>
> Any thoughts?
>
> Regards,
>    Eric
>
>
> > -----Original Message-----
> > From: Keith Bohnenberger [mailto:keith.bohnenberger@mantech.com]
> > Sent: Friday, April 03, 2009 8:15 PM
> > To: user@synapse.apache.org
> > Subject: Re: Custom mediator with the snapshot build
> >
> > Ahh yes. Changing from soap to services did the trick.
> > Where do I look to find these kinds of things for the nightly build?
>



-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

RE: Custom mediator with the snapshot build

Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi,

although it is a quite trivial change from context name /soap to /services we have seen a couple of problems/irritated users, so I asked myself whether it wouldn't be easily possible to configure something in axis2.xml to use /soap as an alias for /services.
This way we could document the change for 1.3 and declare /soap as deprecated and remove it with the next major release.

Any thoughts?

Regards,
   Eric


> -----Original Message-----
> From: Keith Bohnenberger [mailto:keith.bohnenberger@mantech.com]
> Sent: Friday, April 03, 2009 8:15 PM
> To: user@synapse.apache.org
> Subject: Re: Custom mediator with the snapshot build
> 
> Ahh yes. Changing from soap to services did the trick.
> Where do I look to find these kinds of things for the nightly build?

Re: Custom mediator with the snapshot build

Posted by Ruwan Linton <ru...@gmail.com>.
Nice to hear that you got it to work.

If you generate the site, on the trunk you can get the latest documentation.

Thanks,
Ruwan

On Fri, Apr 3, 2009 at 11:44 PM, Keith Bohnenberger <
keith.bohnenberger@mantech.com> wrote:

> Ahh yes. Changing from soap to services did the trick.
> Where do I look to find these kinds of things for the nightly build?
>
>
> On 4/3/09 1:53 PM, "Ruwan Linton" <ru...@gmail.com> wrote:
>
> > Is it possible for you to attach the configuration so that we can check
> it
> > with this.
> >
> > If you are talking to a proxy service the service path should be changed
> > from 'soap' to 'services' it seems the message has been dispatched to the
> > main sequence. Is this particular mediator is on the main sequence??
> >
> > Thanks,
> > Ruwan
> >
> > On Fri, Apr 3, 2009 at 10:08 PM, Keith Bohnenberger <
> > keith.bohnenberger@mantech.com> wrote:
> >
> >> I'm extending AbstractListMediator
> >> The logs don't really show much ...
> >> I see these lines:
> >> 2009-04-03 12:36:22,162 [-] [main]  INFO ProxyService Successfully
> created
> >> the Axis2 service for Proxy service : sendKos
> >> 2009-04-03 12:36:22,163 [-] [main]  INFO Axis2SynapseController Deployed
> >> Proxy service : sendKos
> >>
> >> I can see a log line I have in the constructor when Synapse starts up
> >> I have full logging turned on and I can see the message come through
> when I
> >> send it but then I don't see any log lines that I have in the mediate
> >> method.
> >> After the message gets logged, I see this:
> >> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG LogMediator End :
> >> Log
> >> mediator
> >> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG SequenceMediator
> End
> >> : Sequence <main>
> >> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG ServerWorker
> Sending
> >> 202 Accepted response for MessageID :
> >> urn:uuid:29B8319F9FB38CC3321238776676885 response written : null
> response
> >> will follow : true acked : false forced ack : false
> >>
> >>
> >>
> >>
> >> On 4/3/09 12:21 PM, "Asankha C. Perera" <as...@apache.org> wrote:
> >>
> >>> Keith
> >>>> I have a custom mediator that works fine with the 1.2 release, however
> >> with
> >>>> the nighly build i can see it get deployed in the logs but the
> "mediate"
> >>>> method never seems to get called.  A
> >>>>
> >>>> Any ideas?
> >>>>
> >>> There is some API changes.. does your custom mediator implementing the
> >>> Mediator interface or extending from the AbstractMediator? or is it a
> >>> POJO/class mediator? Can you share the logs and the code for it?
> >>>
> >>> cheers
> >>> asankha
> >>
> >> This communication, along with any attachments, is covered by federal
> and
> >> state law governing electronic communications and may contain company
> >> proprietary and legally privileged information.
> >> If the reader of this message is not the intended recipient, you are
> hereby
> >> notified that any dissemination, distribution, use or copying of this
> >> message is strictly prohibited.
> >> If you have received this in error, please reply immediately to the
> sender
> >> and delete this message.  Thank you.
> >>
> >>
> >
>
> This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain company
> proprietary and legally privileged information.
> If the reader of this message is not the intended recipient, you are hereby
> notified that any dissemination, distribution, use or copying of this
> message is strictly prohibited.
> If you have received this in error, please reply immediately to the sender
> and delete this message.  Thank you.
>
>


-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

RE: Custom mediator with the snapshot build

Posted by "Hubert, Eric" <Er...@foxmobile.com>.
Hi,

although it is a quite trivial change from context name /soap to /services we have seen a couple of problems/irritated users, so I asked myself whether it wouldn't be easily possible to configure something in axis2.xml to use /soap as an alias for /services.
This way we could document the change for 1.3 and declare /soap as deprecated and remove it with the next major release.

Any thoughts?

Regards,
   Eric


> -----Original Message-----
> From: Keith Bohnenberger [mailto:keith.bohnenberger@mantech.com]
> Sent: Friday, April 03, 2009 8:15 PM
> To: user@synapse.apache.org
> Subject: Re: Custom mediator with the snapshot build
> 
> Ahh yes. Changing from soap to services did the trick.
> Where do I look to find these kinds of things for the nightly build?

Re: Custom mediator with the snapshot build

Posted by Keith Bohnenberger <ke...@mantech.com>.
Ahh yes. Changing from soap to services did the trick.
Where do I look to find these kinds of things for the nightly build?


On 4/3/09 1:53 PM, "Ruwan Linton" <ru...@gmail.com> wrote:

> Is it possible for you to attach the configuration so that we can check it
> with this.
> 
> If you are talking to a proxy service the service path should be changed
> from 'soap' to 'services' it seems the message has been dispatched to the
> main sequence. Is this particular mediator is on the main sequence??
> 
> Thanks,
> Ruwan
> 
> On Fri, Apr 3, 2009 at 10:08 PM, Keith Bohnenberger <
> keith.bohnenberger@mantech.com> wrote:
> 
>> I'm extending AbstractListMediator
>> The logs don't really show much ...
>> I see these lines:
>> 2009-04-03 12:36:22,162 [-] [main]  INFO ProxyService Successfully created
>> the Axis2 service for Proxy service : sendKos
>> 2009-04-03 12:36:22,163 [-] [main]  INFO Axis2SynapseController Deployed
>> Proxy service : sendKos
>> 
>> I can see a log line I have in the constructor when Synapse starts up
>> I have full logging turned on and I can see the message come through when I
>> send it but then I don't see any log lines that I have in the mediate
>> method.
>> After the message gets logged, I see this:
>> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG LogMediator End :
>> Log
>> mediator
>> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG SequenceMediator End
>> : Sequence <main>
>> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG ServerWorker Sending
>> 202 Accepted response for MessageID :
>> urn:uuid:29B8319F9FB38CC3321238776676885 response written : null response
>> will follow : true acked : false forced ack : false
>> 
>> 
>> 
>> 
>> On 4/3/09 12:21 PM, "Asankha C. Perera" <as...@apache.org> wrote:
>> 
>>> Keith
>>>> I have a custom mediator that works fine with the 1.2 release, however
>> with
>>>> the nighly build i can see it get deployed in the logs but the "mediate"
>>>> method never seems to get called.  A
>>>> 
>>>> Any ideas?
>>>> 
>>> There is some API changes.. does your custom mediator implementing the
>>> Mediator interface or extending from the AbstractMediator? or is it a
>>> POJO/class mediator? Can you share the logs and the code for it?
>>> 
>>> cheers
>>> asankha
>> 
>> This communication, along with any attachments, is covered by federal and
>> state law governing electronic communications and may contain company
>> proprietary and legally privileged information.
>> If the reader of this message is not the intended recipient, you are hereby
>> notified that any dissemination, distribution, use or copying of this
>> message is strictly prohibited.
>> If you have received this in error, please reply immediately to the sender
>> and delete this message.  Thank you.
>> 
>> 
> 

This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information.  
If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  
If you have received this in error, please reply immediately to the sender and delete this message.  Thank you.


Re: Custom mediator with the snapshot build

Posted by Ruwan Linton <ru...@gmail.com>.
Is it possible for you to attach the configuration so that we can check it
with this.

If you are talking to a proxy service the service path should be changed
from 'soap' to 'services' it seems the message has been dispatched to the
main sequence. Is this particular mediator is on the main sequence??

Thanks,
Ruwan

On Fri, Apr 3, 2009 at 10:08 PM, Keith Bohnenberger <
keith.bohnenberger@mantech.com> wrote:

> I'm extending AbstractListMediator
> The logs don't really show much ...
> I see these lines:
> 2009-04-03 12:36:22,162 [-] [main]  INFO ProxyService Successfully created
> the Axis2 service for Proxy service : sendKos
> 2009-04-03 12:36:22,163 [-] [main]  INFO Axis2SynapseController Deployed
> Proxy service : sendKos
>
> I can see a log line I have in the constructor when Synapse starts up
> I have full logging turned on and I can see the message come through when I
> send it but then I don't see any log lines that I have in the mediate
> method.
> After the message gets logged, I see this:
> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG LogMediator End :
> Log
> mediator
> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG SequenceMediator End
> : Sequence <main>
> 2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG ServerWorker Sending
> 202 Accepted response for MessageID :
> urn:uuid:29B8319F9FB38CC3321238776676885 response written : null response
> will follow : true acked : false forced ack : false
>
>
>
>
> On 4/3/09 12:21 PM, "Asankha C. Perera" <as...@apache.org> wrote:
>
> > Keith
> >> I have a custom mediator that works fine with the 1.2 release, however
> with
> >> the nighly build i can see it get deployed in the logs but the "mediate"
> >> method never seems to get called.  A
> >>
> >> Any ideas?
> >>
> > There is some API changes.. does your custom mediator implementing the
> > Mediator interface or extending from the AbstractMediator? or is it a
> > POJO/class mediator? Can you share the logs and the code for it?
> >
> > cheers
> > asankha
>
> This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain company
> proprietary and legally privileged information.
> If the reader of this message is not the intended recipient, you are hereby
> notified that any dissemination, distribution, use or copying of this
> message is strictly prohibited.
> If you have received this in error, please reply immediately to the sender
> and delete this message.  Thank you.
>
>


-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Re: Custom mediator with the snapshot build

Posted by Keith Bohnenberger <ke...@mantech.com>.
I'm extending AbstractListMediator
The logs don't really show much ...
I see these lines:
2009-04-03 12:36:22,162 [-] [main]  INFO ProxyService Successfully created
the Axis2 service for Proxy service : sendKos
2009-04-03 12:36:22,163 [-] [main]  INFO Axis2SynapseController Deployed
Proxy service : sendKos

I can see a log line I have in the constructor when Synapse starts up
I have full logging turned on and I can see the message come through when I
send it but then I don't see any log lines that I have in the mediate
method.
After the message gets logged, I see this:
2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG LogMediator End : Log
mediator
2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG SequenceMediator End
: Sequence <main>
2009-04-03 12:37:56,981 [-] [HttpServerWorker-1] DEBUG ServerWorker Sending
202 Accepted response for MessageID :
urn:uuid:29B8319F9FB38CC3321238776676885 response written : null response
will follow : true acked : false forced ack : false




On 4/3/09 12:21 PM, "Asankha C. Perera" <as...@apache.org> wrote:

> Keith
>> I have a custom mediator that works fine with the 1.2 release, however with
>> the nighly build i can see it get deployed in the logs but the "mediate"
>> method never seems to get called.  A
>> 
>> Any ideas?
>>   
> There is some API changes.. does your custom mediator implementing the
> Mediator interface or extending from the AbstractMediator? or is it a
> POJO/class mediator? Can you share the logs and the code for it?
> 
> cheers
> asankha

This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information.  
If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  
If you have received this in error, please reply immediately to the sender and delete this message.  Thank you.


Re: Custom mediator with the snapshot build

Posted by "Asankha C. Perera" <as...@apache.org>.
Keith
> I have a custom mediator that works fine with the 1.2 release, however with
> the nighly build i can see it get deployed in the logs but the "mediate"
> method never seems to get called.  A
>
> Any ideas?
>   
There is some API changes.. does your custom mediator implementing the 
Mediator interface or extending from the AbstractMediator? or is it a 
POJO/class mediator? Can you share the logs and the code for it?

cheers
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com