Re: Custom mediator with the snapshot build

[Ruwan Linton]

On Sat, Apr 4, 2009 at 10:58 PM, Hubert, Eric 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: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

RE: Custom mediator with the snapshot build

[Hubert, Eric]

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

[Asankha C. Perera]

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

[Ruwan Linton]

On Sat, Apr 4, 2009 at 9:29 PM, Asankha C. Perera wrote:

>  Hi Ruwan
>
> On Sat, Apr 4, 2009 at 9:00 PM, Asankha C. Perera 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..
>
> services
>
> 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: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Re: Custom mediator with the snapshot build

[Asankha C. Perera]

Hi Ruwan
On Sat, Apr 4, 2009 at 9:00 PM, Asankha C. Perera > 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..


services

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

[Ruwan Linton]

On Sat, Apr 4, 2009 at 9:00 PM, Asankha C. Perera 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 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: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Re: Custom mediator with the snapshot build

[Asankha C. Perera]

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 
mailto:eric.hub...@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

[Ruwan Linton]

AFAIK, axis2 doesn't support this sort of a aliasing.

Thanks,
Ruwan

On Sat, Apr 4, 2009 at 1:04 AM, Hubert, Eric 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.bohnenber...@mantech.com]
> > Sent: Friday, April 03, 2009 8:15 PM
> > To: u...@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: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

RE: Custom mediator with the snapshot build

[Hubert, Eric]

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.bohnenber...@mantech.com]
> Sent: Friday, April 03, 2009 8:15 PM
> To: u...@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?