Hi,
I'm still not convinced about the granularity issue :) . Let me take an
example. We'll take the deployCartridgeDefinition() method in the Cloud
Controller service.
With SOAP, we've used two custom exceptions,
*InvalidCartridgeDefinitionException* and *InvalidIaasProviderException*
which indicate two different errors. In REST speak both these errors will
be "*400 Bad Request*" responses with specific details in the message body.
To differentiate between the errors, we would be doing String comparisons,
which would break easily if we change the message body in the server.
I might be wrong here because I'm comparing the service methods as they are
to REST. When changing to REST, the service interface would most probably
be changed too, and therefore, these concerns might be resolved
automatically.
This said, I'm still +1 for switching to REST, because of the other
advantages we'd be having.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Sun, May 10, 2015 at 7:06 PM, Gayan Gunarathne <gay...@wso2.com> wrote:
> Hi,
>
> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <chami...@wso2.com>
> wrote:
>
>> Hi,
>>
>> Is the possibility of upgrading to a newer version of Axis2 available (if
>> we are using an older version) ?
>>
> +1. IMO also we can try with the newer version of Axis2
>
>> We might lose the granularity in the responses (currently we use custom
>> exceptions) if we switch to REST as the protocol between the components
>>
> I don't think we lose the granularity in the responses if we are using the
> REST. We can introduce the custom error messages with response message
> itself if we need more granularity.HTTP status code is the one use only for
> HTTP specific error codes. We don't need to restrict only for HTTP status
> codes.
>
>
>> (we'd have to use HTTP status codes, but they can be granular only up to
>> a certain level. After that we'd be down to String comparison). However
>> w.r.t both unnecessary complexity and convoluted development process
>> switching to REST sounds good. Shall we add this as an exploratory task for
>> a future release?
>> On May 10, 2015 10:31 AM, "Lahiru Sandaruwan" <lahi...@wso2.com> wrote:
>>
>>> Hi Udara,
>>>
>>>
>>> On Sun, May 10, 2015 at 10:17 AM, Udara Liyanage <ud...@wso2.com> wrote:
>>>
>>>> Hi Lahiru,
>>>>
>>>> I have few concerns about the former method
>>>>
>>>> * How would you do the first approach for the service method which are
>>>> actually returning a boolean value?
>>>>
>>>
>>> If there is a return value(Boolean or anything), this problem is not
>>> there.
>>>
>>> *Say we change void to boolean, then a how can the exact exception cab
>>>> be passed down to the client since the method may fail due to multiple
>>>> exception
>>>>
>>>
>>> All the specific exceptions will be correctly passed. This seems an
>>> issue with Axis2. See the other thread where Chamila explained the issue as
>>> follows,
>>>
>>> "The issue with custom exceptions not being returned was that in the
>>> stub when recreating the exception, in the returned AxisFault, 'detail'
>>> field is being set to null."
>>>
>>> So the details field does not become null when there is a non 'void'
>>> return type. So any custom exception can be catched.
>>>
>>> * Is it a good practice to change return type just for catching
>>>> exceptions
>>>>
>>>
>>> No. But this will be a fair workaround, since we are planning to migrate
>>> AS/CC services to Rest services ASAP.
>>>
>>> Thanks.
>>>
>>>>
>>>>
>>>> On Sun, May 10, 2015 at 10:11 AM, Lahiru Sandaruwan <lahi...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have been looking into solving issues in $subject. Found that,
>>>>> currently if the back end service method return type is void, service stub
>>>>> throws an AxisFault with the message of custom exception message, but not
>>>>> the exact exception.
>>>>>
>>>>> One solution is, to have a boolean return value, for the methods that
>>>>> are having return type void, for the purpose of catching custom
>>>>> exceptions.
>>>>>
>>>>> According to [1], we can throw custom exceptions as below and catch as
>>>>> well.
>>>>>
>>>>> throw new AxisFault(new QName("http://test.org";, "FaultCode",
>>>>> "test"), "FaultReason", new Exception("This is a test Exception"));
>>>>>
>>>>> But i prefer former way as it is crystal clear. Shall we go ahead with
>>>>> that?
>>>>>
>>>>> Wdyt?
>>>>>
>>>>> [1] http://wso2.com/library/171/
>>>>>
>>>>> Thanks.
>>>>> --
>>>>> --
>>>>> Lahiru Sandaruwan
>>>>> Committer and PMC member, Apache Stratos,
>>>>> Senior Software Engineer,
>>>>> WSO2 Inc., http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> phone: +94773325954
>>>>> email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/
>>>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Udara Liyanage
>>>> Software Engineer
>>>> WSO2, Inc.: http://wso2.com
>>>> lean. enterprise. middleware
>>>>
>>>> web: http://udaraliyanage.wordpress.com
>>>> phone: +94 71 443 6897
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Lahiru Sandaruwan
>>> Committer and PMC member, Apache Stratos,
>>> Senior Software Engineer,
>>> WSO2 Inc., http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> phone: +94773325954
>>> email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/
>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>
>>>
>
>
> --
>
> Gayan Gunarathne
> Technical Lead
> WSO2 Inc. (http://wso2.com)
> email : gay...@wso2.com | mobile : +94 766819985
>
>
