You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Lahiru Sandaruwan <la...@wso2.com> on 2015/05/10 06:41:23 UTC
[Discuss] How to handle errors at server side in AS/CC services
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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Lakmal Warusawithana <la...@wso2.com>.
Yes, don't try these stuff last movement please.
On Mon, May 11, 2015 at 12:34 AM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Larhiru,
>
> Thanks for the findings!! IMO it would be better to go ahead with the
> workaround for the time being. Otherwise we would have to spend
> considerable amount of effort on upgrading Axis2.
>
> Thanks
>
> On Mon, May 11, 2015 at 12:30 AM, Lahiru Sandaruwan <la...@wso2.com>
> wrote:
>
>> Hi,
>>
>> I built the pack without integration tests. But it is broken as i can't
>> even log into it. We would have to put some effort to do this migrations
>> since it might require Carbon migrations as well. So it won't be a viable
>> solution for this release as we are at the verge of it, IMO.
>>
>> Thanks.
>>
>> On Mon, May 11, 2015 at 12:22 AM, Lahiru Sandaruwan <la...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Downloading issues is fixed with a clean repo attempt. However i got a
>>> failure at "org.apache.stratos.email" due to a missing constant class. I
>>> continued with bringing class to our source. But, it again fails at
>>> integration tests with error [1].
>>>
>>> Looking bit further.
>>>
>>> Thanks.
>>>
>>> [1]
>>>
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} -
>>> [2015-05-11 00:08:15,133] ERROR
>>> {org.wso2.carbon.server.admin.module.handler.AuthenticationHandler} -
>>> org/apache/axis2/transport/http/HTTPConstants
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} -
>>> java.lang.NoClassDefFoundError:
>>> org/apache/axis2/transport/http/HTTPConstants
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.apache.stratos.custom.handlers.authentication.SignedJWTAuthenticator.isHandle(SignedJWTAuthenticator.java:149)
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.wso2.carbon.server.admin.auth.AuthenticatorServerRegistry.canHandle(AuthenticatorServerRegistry.java:115)
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.wso2.carbon.server.admin.auth.AuthenticatorServerRegistry.getCarbonAuthenticator(AuthenticatorServerRegistry.java:101)
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.isAuthenticated(AuthenticationHandler.java:149)
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.authenticate(AuthenticationHandler.java:96)
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.invoke(AuthenticationHandler.java:66)
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.apache.axis2.engine.Phase.invokeHandler(Phase.java:340)
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.apache.axis2.engine.Phase.invoke(Phase.java:313)
>>> [2015-05-11 00:08:15,134] INFO
>>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>>> org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:261)
>>>
>>>
>>> On Sun, May 10, 2015 at 10:53 PM, Lahiru Sandaruwan <la...@wso2.com>
>>> wrote:
>>>
>>>> Hi Imesh,
>>>>
>>>> On Sun, May 10, 2015 at 12:36 PM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>
>>>>> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Is the possibility of upgrading to a newer version of Axis2 available
>>>>>> (if we are using an older version) ?
>>>>>>
>>>>> Yes that's possible, currently we are using 1.6.1-wso2v10 and in nexus
>>>>> we have 1.6.1-wso2v12 [1]. @Lahiru: Would you mind giving this a try?
>>>>>
>>>>
>>>> I gave it a try with new version with no luck. I tried with following
>>>> repository as well.
>>>>
>>>> <repository>
>>>> <id>wso2.releases</id>
>>>> <name>WSO2 internal Repository</name>
>>>> <url>
>>>> http://maven.wso2.org/nexus/content/repositories/releases/</url>
>>>> <releases>
>>>> <enabled>true</enabled>
>>>> <updatePolicy>daily</updatePolicy>
>>>> <checksumPolicy>ignore</checksumPolicy>
>>>> </releases>
>>>> </repository>
>>>>
>>>> But the it fails to download the jar at the build. Let me know if you
>>>> know any other repo.
>>>>
>>>> Thanks.
>>>>
>>>>> We might lose the granularity in the responses (currently we use
>>>>>> custom exceptions) if we switch to REST as the protocol between the
>>>>>> components (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).
>>>>>>
>>>>> I tend to disagree with this statement, when two software components
>>>>> are communicating with SOAP, it is possible to use exceptions for
>>>>> communicating errors. This helps the client to identify the errors by
>>>>> looking at the exceptions.
>>>>>
>>>>> However it does not mean that we need to do the same with any other
>>>>> type of a web service framework. REST by design is different than SOAP.
>>>>> With REST we could use response messages with error codes if we need to
>>>>> identify specific errors. Otherwise the client could directly display the
>>>>> error message given in the response message. IMO this does not mean that we
>>>>> are loosing granularity in the responses.
>>>>>
>>>>> Yes definitely, we will have a separate discussion on this topic and
>>>>> add a future task to implement it if we decide to go on that approach.
>>>>>
>>>>> [1]
>>>>> http://maven.wso2.org/nexus/content/groups/wso2-public/org/apache/axis2/axis2/1.6.1-wso2v12/
>>>>>
>>>>> Thanks
>>>>>
>>>>> --
>>>>> Imesh Gunaratne
>>>>>
>>>>> Senior Technical Lead, WSO2
>>>>> Committer & PMC Member, Apache Stratos
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Lahiru Sandaruwan
>>>> Committer and PMC member, Apache Stratos,
>>>> Senior Software Engineer,
>>>> WSO2 Inc., http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> phone: +94773325954
>>>> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Lahiru Sandaruwan
>>> Committer and PMC member, Apache Stratos,
>>> Senior Software Engineer,
>>> WSO2 Inc., http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> phone: +94773325954
>>> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>
>>>
>>
>>
>> --
>> --
>> Lahiru Sandaruwan
>> Committer and PMC member, Apache Stratos,
>> Senior Software Engineer,
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> phone: +94773325954
>> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>
>
> --
> Imesh Gunaratne
>
> Senior Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
Lakmal Warusawithana
Vice President, Apache Stratos
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blog : http://lakmalsview.blogspot.com/
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Larhiru,
Thanks for the findings!! IMO it would be better to go ahead with the
workaround for the time being. Otherwise we would have to spend
considerable amount of effort on upgrading Axis2.
Thanks
On Mon, May 11, 2015 at 12:30 AM, Lahiru Sandaruwan <la...@wso2.com>
wrote:
> Hi,
>
> I built the pack without integration tests. But it is broken as i can't
> even log into it. We would have to put some effort to do this migrations
> since it might require Carbon migrations as well. So it won't be a viable
> solution for this release as we are at the verge of it, IMO.
>
> Thanks.
>
> On Mon, May 11, 2015 at 12:22 AM, Lahiru Sandaruwan <la...@wso2.com>
> wrote:
>
>> Hi,
>>
>> Downloading issues is fixed with a clean repo attempt. However i got a
>> failure at "org.apache.stratos.email" due to a missing constant class. I
>> continued with bringing class to our source. But, it again fails at
>> integration tests with error [1].
>>
>> Looking bit further.
>>
>> Thanks.
>>
>> [1]
>>
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} -
>> [2015-05-11 00:08:15,133] ERROR
>> {org.wso2.carbon.server.admin.module.handler.AuthenticationHandler} -
>> org/apache/axis2/transport/http/HTTPConstants
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} -
>> java.lang.NoClassDefFoundError:
>> org/apache/axis2/transport/http/HTTPConstants
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.apache.stratos.custom.handlers.authentication.SignedJWTAuthenticator.isHandle(SignedJWTAuthenticator.java:149)
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.wso2.carbon.server.admin.auth.AuthenticatorServerRegistry.canHandle(AuthenticatorServerRegistry.java:115)
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.wso2.carbon.server.admin.auth.AuthenticatorServerRegistry.getCarbonAuthenticator(AuthenticatorServerRegistry.java:101)
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.isAuthenticated(AuthenticationHandler.java:149)
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.authenticate(AuthenticationHandler.java:96)
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.invoke(AuthenticationHandler.java:66)
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.apache.axis2.engine.Phase.invokeHandler(Phase.java:340)
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.apache.axis2.engine.Phase.invoke(Phase.java:313)
>> [2015-05-11 00:08:15,134] INFO
>> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
>> org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:261)
>>
>>
>> On Sun, May 10, 2015 at 10:53 PM, Lahiru Sandaruwan <la...@wso2.com>
>> wrote:
>>
>>> Hi Imesh,
>>>
>>> On Sun, May 10, 2015 at 12:36 PM, Imesh Gunaratne <im...@apache.org>
>>> wrote:
>>>
>>>> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Is the possibility of upgrading to a newer version of Axis2 available
>>>>> (if we are using an older version) ?
>>>>>
>>>> Yes that's possible, currently we are using 1.6.1-wso2v10 and in nexus
>>>> we have 1.6.1-wso2v12 [1]. @Lahiru: Would you mind giving this a try?
>>>>
>>>
>>> I gave it a try with new version with no luck. I tried with following
>>> repository as well.
>>>
>>> <repository>
>>> <id>wso2.releases</id>
>>> <name>WSO2 internal Repository</name>
>>> <url>
>>> http://maven.wso2.org/nexus/content/repositories/releases/</url>
>>> <releases>
>>> <enabled>true</enabled>
>>> <updatePolicy>daily</updatePolicy>
>>> <checksumPolicy>ignore</checksumPolicy>
>>> </releases>
>>> </repository>
>>>
>>> But the it fails to download the jar at the build. Let me know if you
>>> know any other repo.
>>>
>>> Thanks.
>>>
>>>> We might lose the granularity in the responses (currently we use custom
>>>>> exceptions) if we switch to REST as the protocol between the components
>>>>> (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).
>>>>>
>>>> I tend to disagree with this statement, when two software components
>>>> are communicating with SOAP, it is possible to use exceptions for
>>>> communicating errors. This helps the client to identify the errors by
>>>> looking at the exceptions.
>>>>
>>>> However it does not mean that we need to do the same with any other
>>>> type of a web service framework. REST by design is different than SOAP.
>>>> With REST we could use response messages with error codes if we need to
>>>> identify specific errors. Otherwise the client could directly display the
>>>> error message given in the response message. IMO this does not mean that we
>>>> are loosing granularity in the responses.
>>>>
>>>> Yes definitely, we will have a separate discussion on this topic and
>>>> add a future task to implement it if we decide to go on that approach.
>>>>
>>>> [1]
>>>> http://maven.wso2.org/nexus/content/groups/wso2-public/org/apache/axis2/axis2/1.6.1-wso2v12/
>>>>
>>>> Thanks
>>>>
>>>> --
>>>> Imesh Gunaratne
>>>>
>>>> Senior Technical Lead, WSO2
>>>> Committer & PMC Member, Apache Stratos
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> Lahiru Sandaruwan
>>> Committer and PMC member, Apache Stratos,
>>> Senior Software Engineer,
>>> WSO2 Inc., http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> phone: +94773325954
>>> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>
>>>
>>
>>
>> --
>> --
>> Lahiru Sandaruwan
>> Committer and PMC member, Apache Stratos,
>> Senior Software Engineer,
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> phone: +94773325954
>> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>
>
> --
> --
> Lahiru Sandaruwan
> Committer and PMC member, Apache Stratos,
> Senior Software Engineer,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> phone: +94773325954
> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
--
Imesh Gunaratne
Senior Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi,
I built the pack without integration tests. But it is broken as i can't
even log into it. We would have to put some effort to do this migrations
since it might require Carbon migrations as well. So it won't be a viable
solution for this release as we are at the verge of it, IMO.
Thanks.
On Mon, May 11, 2015 at 12:22 AM, Lahiru Sandaruwan <la...@wso2.com>
wrote:
> Hi,
>
> Downloading issues is fixed with a clean repo attempt. However i got a
> failure at "org.apache.stratos.email" due to a missing constant class. I
> continued with bringing class to our source. But, it again fails at
> integration tests with error [1].
>
> Looking bit further.
>
> Thanks.
>
> [1]
>
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} -
> [2015-05-11 00:08:15,133] ERROR
> {org.wso2.carbon.server.admin.module.handler.AuthenticationHandler} -
> org/apache/axis2/transport/http/HTTPConstants
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} -
> java.lang.NoClassDefFoundError:
> org/apache/axis2/transport/http/HTTPConstants
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.apache.stratos.custom.handlers.authentication.SignedJWTAuthenticator.isHandle(SignedJWTAuthenticator.java:149)
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.wso2.carbon.server.admin.auth.AuthenticatorServerRegistry.canHandle(AuthenticatorServerRegistry.java:115)
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.wso2.carbon.server.admin.auth.AuthenticatorServerRegistry.getCarbonAuthenticator(AuthenticatorServerRegistry.java:101)
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.isAuthenticated(AuthenticationHandler.java:149)
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.authenticate(AuthenticationHandler.java:96)
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.invoke(AuthenticationHandler.java:66)
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.apache.axis2.engine.Phase.invokeHandler(Phase.java:340)
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.apache.axis2.engine.Phase.invoke(Phase.java:313)
> [2015-05-11 00:08:15,134] INFO
> {org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
> org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:261)
>
>
> On Sun, May 10, 2015 at 10:53 PM, Lahiru Sandaruwan <la...@wso2.com>
> wrote:
>
>> Hi Imesh,
>>
>> On Sun, May 10, 2015 at 12:36 PM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@wso2.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Is the possibility of upgrading to a newer version of Axis2 available
>>>> (if we are using an older version) ?
>>>>
>>> Yes that's possible, currently we are using 1.6.1-wso2v10 and in nexus
>>> we have 1.6.1-wso2v12 [1]. @Lahiru: Would you mind giving this a try?
>>>
>>
>> I gave it a try with new version with no luck. I tried with following
>> repository as well.
>>
>> <repository>
>> <id>wso2.releases</id>
>> <name>WSO2 internal Repository</name>
>> <url>
>> http://maven.wso2.org/nexus/content/repositories/releases/</url>
>> <releases>
>> <enabled>true</enabled>
>> <updatePolicy>daily</updatePolicy>
>> <checksumPolicy>ignore</checksumPolicy>
>> </releases>
>> </repository>
>>
>> But the it fails to download the jar at the build. Let me know if you
>> know any other repo.
>>
>> Thanks.
>>
>>> We might lose the granularity in the responses (currently we use custom
>>>> exceptions) if we switch to REST as the protocol between the components
>>>> (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).
>>>>
>>> I tend to disagree with this statement, when two software components are
>>> communicating with SOAP, it is possible to use exceptions for communicating
>>> errors. This helps the client to identify the errors by looking at the
>>> exceptions.
>>>
>>> However it does not mean that we need to do the same with any other type
>>> of a web service framework. REST by design is different than SOAP. With
>>> REST we could use response messages with error codes if we need to identify
>>> specific errors. Otherwise the client could directly display the error
>>> message given in the response message. IMO this does not mean that we are
>>> loosing granularity in the responses.
>>>
>>> Yes definitely, we will have a separate discussion on this topic and add
>>> a future task to implement it if we decide to go on that approach.
>>>
>>> [1]
>>> http://maven.wso2.org/nexus/content/groups/wso2-public/org/apache/axis2/axis2/1.6.1-wso2v12/
>>>
>>> Thanks
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Senior Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> --
>> Lahiru Sandaruwan
>> Committer and PMC member, Apache Stratos,
>> Senior Software Engineer,
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> phone: +94773325954
>> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
>
>
> --
> --
> Lahiru Sandaruwan
> Committer and PMC member, Apache Stratos,
> Senior Software Engineer,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> phone: +94773325954
> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
phone: +94773325954
email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi,
Downloading issues is fixed with a clean repo attempt. However i got a
failure at "org.apache.stratos.email" due to a missing constant class. I
continued with bringing class to our source. But, it again fails at
integration tests with error [1].
Looking bit further.
Thanks.
[1]
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} -
[2015-05-11 00:08:15,133] ERROR
{org.wso2.carbon.server.admin.module.handler.AuthenticationHandler} -
org/apache/axis2/transport/http/HTTPConstants
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} -
java.lang.NoClassDefFoundError:
org/apache/axis2/transport/http/HTTPConstants
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.apache.stratos.custom.handlers.authentication.SignedJWTAuthenticator.isHandle(SignedJWTAuthenticator.java:149)
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.wso2.carbon.server.admin.auth.AuthenticatorServerRegistry.canHandle(AuthenticatorServerRegistry.java:115)
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.wso2.carbon.server.admin.auth.AuthenticatorServerRegistry.getCarbonAuthenticator(AuthenticatorServerRegistry.java:101)
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.isAuthenticated(AuthenticationHandler.java:149)
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.authenticate(AuthenticationHandler.java:96)
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.wso2.carbon.server.admin.module.handler.AuthenticationHandler.invoke(AuthenticationHandler.java:66)
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.apache.axis2.engine.Phase.invokeHandler(Phase.java:340)
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.apache.axis2.engine.Phase.invoke(Phase.java:313)
[2015-05-11 00:08:15,134] INFO
{org.wso2.carbon.integration.framework.utils.InputStreamHandler} - at
org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:261)
On Sun, May 10, 2015 at 10:53 PM, Lahiru Sandaruwan <la...@wso2.com>
wrote:
> Hi Imesh,
>
> On Sun, May 10, 2015 at 12:36 PM, Imesh Gunaratne <im...@apache.org>
> wrote:
>
>> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Is the possibility of upgrading to a newer version of Axis2 available
>>> (if we are using an older version) ?
>>>
>> Yes that's possible, currently we are using 1.6.1-wso2v10 and in nexus we
>> have 1.6.1-wso2v12 [1]. @Lahiru: Would you mind giving this a try?
>>
>
> I gave it a try with new version with no luck. I tried with following
> repository as well.
>
> <repository>
> <id>wso2.releases</id>
> <name>WSO2 internal Repository</name>
> <url>
> http://maven.wso2.org/nexus/content/repositories/releases/</url>
> <releases>
> <enabled>true</enabled>
> <updatePolicy>daily</updatePolicy>
> <checksumPolicy>ignore</checksumPolicy>
> </releases>
> </repository>
>
> But the it fails to download the jar at the build. Let me know if you know
> any other repo.
>
> Thanks.
>
>> We might lose the granularity in the responses (currently we use custom
>>> exceptions) if we switch to REST as the protocol between the components
>>> (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).
>>>
>> I tend to disagree with this statement, when two software components are
>> communicating with SOAP, it is possible to use exceptions for communicating
>> errors. This helps the client to identify the errors by looking at the
>> exceptions.
>>
>> However it does not mean that we need to do the same with any other type
>> of a web service framework. REST by design is different than SOAP. With
>> REST we could use response messages with error codes if we need to identify
>> specific errors. Otherwise the client could directly display the error
>> message given in the response message. IMO this does not mean that we are
>> loosing granularity in the responses.
>>
>> Yes definitely, we will have a separate discussion on this topic and add
>> a future task to implement it if we decide to go on that approach.
>>
>> [1]
>> http://maven.wso2.org/nexus/content/groups/wso2-public/org/apache/axis2/axis2/1.6.1-wso2v12/
>>
>> Thanks
>>
>> --
>> Imesh Gunaratne
>>
>> Senior Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> --
> Lahiru Sandaruwan
> Committer and PMC member, Apache Stratos,
> Senior Software Engineer,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> phone: +94773325954
> email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
phone: +94773325954
email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi Imesh,
On Sun, May 10, 2015 at 12:36 PM, Imesh Gunaratne <im...@apache.org> wrote:
> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@wso2.com>
> wrote:
>
>> Hi,
>>
>> Is the possibility of upgrading to a newer version of Axis2 available (if
>> we are using an older version) ?
>>
> Yes that's possible, currently we are using 1.6.1-wso2v10 and in nexus we
> have 1.6.1-wso2v12 [1]. @Lahiru: Would you mind giving this a try?
>
I gave it a try with new version with no luck. I tried with following
repository as well.
<repository>
<id>wso2.releases</id>
<name>WSO2 internal Repository</name>
<url>http://maven.wso2.org/nexus/content/repositories/releases/
</url>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</releases>
</repository>
But the it fails to download the jar at the build. Let me know if you know
any other repo.
Thanks.
> We might lose the granularity in the responses (currently we use custom
>> exceptions) if we switch to REST as the protocol between the components
>> (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).
>>
> I tend to disagree with this statement, when two software components are
> communicating with SOAP, it is possible to use exceptions for communicating
> errors. This helps the client to identify the errors by looking at the
> exceptions.
>
> However it does not mean that we need to do the same with any other type
> of a web service framework. REST by design is different than SOAP. With
> REST we could use response messages with error codes if we need to identify
> specific errors. Otherwise the client could directly display the error
> message given in the response message. IMO this does not mean that we are
> loosing granularity in the responses.
>
> Yes definitely, we will have a separate discussion on this topic and add a
> future task to implement it if we decide to go on that approach.
>
> [1]
> http://maven.wso2.org/nexus/content/groups/wso2-public/org/apache/axis2/axis2/1.6.1-wso2v12/
>
> Thanks
>
> --
> Imesh Gunaratne
>
> Senior Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
phone: +94773325954
email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Imesh Gunaratne <im...@apache.org>.
On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@wso2.com>
wrote:
> Hi,
>
> Is the possibility of upgrading to a newer version of Axis2 available (if
> we are using an older version) ?
>
Yes that's possible, currently we are using 1.6.1-wso2v10 and in nexus we
have 1.6.1-wso2v12 [1]. @Lahiru: Would you mind giving this a try?
> We might lose the granularity in the responses (currently we use custom
> exceptions) if we switch to REST as the protocol between the components
> (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).
>
I tend to disagree with this statement, when two software components are
communicating with SOAP, it is possible to use exceptions for communicating
errors. This helps the client to identify the errors by looking at the
exceptions.
However it does not mean that we need to do the same with any other type of
a web service framework. REST by design is different than SOAP. With REST
we could use response messages with error codes if we need to identify
specific errors. Otherwise the client could directly display the error
message given in the response message. IMO this does not mean that we are
loosing granularity in the responses.
Yes definitely, we will have a separate discussion on this topic and add a
future task to implement it if we decide to go on that approach.
[1]
http://maven.wso2.org/nexus/content/groups/wso2-public/org/apache/axis2/axis2/1.6.1-wso2v12/
Thanks
--
Imesh Gunaratne
Senior Technical Lead, WSO2
Committer & PMC Member, Apache Stratos
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Chamila De Alwis <ch...@wso2.com>.
Bad example because deployCartridgeDefinition() is not there in CC anymore
:) . It should be addCartridge() with custom exceptions
* InvalidCartridgeDefinitionException, ** InvalidIaasProviderException, *and*
CartridgeAlreadyExistsException*.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Sun, May 10, 2015 at 8:41 PM, Chamila De Alwis <ch...@wso2.com> wrote:
> 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 <ga...@wso2.com> wrote:
>
>> Hi,
>>
>> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@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" <la...@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 <la...@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: lahirus@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: lahirus@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 : gayang@wso2.com | mobile : +94 766819985
>>
>>
>
>
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Lahiru Sandaruwan <la...@wso2.com>.
On Sun, May 10, 2015 at 11:00 PM, Chamila De Alwis <ch...@wso2.com>
wrote:
> Hi Lahiru,
> On Sun, May 10, 2015 at 8:56 PM, Lahiru Sandaruwan <la...@wso2.com>
> wrote:
>
>> So what we need to do at Stratos Rest API(The API we have now), is to
>> catch the status code and message from CC Rest API and send both, as they
>> are, to end user. No String comparison required.
>>
>
> Wouldn't there be inter-component communication that needs to make
> decisions based on the response? For example AS makes calls to CC and
> decides what to do based on the exception type?
>
I think answer is local error codes. This will improve granularity as much
as we want. See #5 at [1].
Thanks.
[1]
http://devproconnections.com/web-development/restful-api-development-best-practices
>
> Anyways, we are already doing String comparisons because of the initial
> issue of custom exceptions not being passed to the client. I'm sure we will
> be able to circumvent this problem at the time of service design.
>
>
> Regards,
> Chamila de Alwis
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
phone: +94773325954
email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Chamila De Alwis <ch...@wso2.com>.
Hi Lahiru,
On Sun, May 10, 2015 at 8:56 PM, Lahiru Sandaruwan <la...@wso2.com> wrote:
> So what we need to do at Stratos Rest API(The API we have now), is to
> catch the status code and message from CC Rest API and send both, as they
> are, to end user. No String comparison required.
>
Wouldn't there be inter-component communication that needs to make
decisions based on the response? For example AS makes calls to CC and
decides what to do based on the exception type?
Anyways, we are already doing String comparisons because of the initial
issue of custom exceptions not being passed to the client. I'm sure we will
be able to circumvent this problem at the time of service design.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi Chamila,
On Sun, May 10, 2015 at 8:41 PM, Chamila De Alwis <ch...@wso2.com> wrote:
> 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.
>
Let us consider the Stratos as a back box. Then the end user of that box is
the person who send the deploy cartridge request.
He is only interested in the status code and the message(in fact, that's
the only thing he get).
So what we need to do at Stratos Rest API(The API we have now), is to catch
the status code and message from CC Rest API and send both, as they are, to
end user. No String comparison required.
Am i missing anything?
Thanks.
> 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 <ga...@wso2.com> wrote:
>
>> Hi,
>>
>> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@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" <la...@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 <la...@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: lahirus@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: lahirus@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 : gayang@wso2.com | mobile : +94 766819985
>>
>>
>
>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
phone: +94773325954
email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Chamila De Alwis <ch...@wso2.com>.
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 <ga...@wso2.com> wrote:
> Hi,
>
> On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@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" <la...@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 <la...@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: lahirus@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: lahirus@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 : gayang@wso2.com | mobile : +94 766819985
>
>
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Gayan Gunarathne <ga...@wso2.com>.
Hi,
On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@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" <la...@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 <la...@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: lahirus@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: lahirus@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 : gayang@wso2.com | mobile : +94 766819985
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi Chamila,
Find the comment inline,
On Sun, May 10, 2015 at 12:08 PM, Chamila De Alwis <ch...@wso2.com>
wrote:
> Hi,
>
> Is the possibility of upgrading to a newer version of Axis2 available (if
> we are using an older version) ?
>
> We might lose the granularity in the responses (currently we use custom
> exceptions) if we switch to REST as the protocol between the components
> (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).
>
Agree. But i'm not sure if we need that level of granularity.
Because all the service methods that are called from client requests are
coming through Stratos Rest API. Therefore we only need status code level
of granularity AFAIU. We can log specific errors in backend.
Thanks.
> 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" <la...@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 <la...@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: lahirus@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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>
>>
--
--
Lahiru Sandaruwan
Committer and PMC member, Apache Stratos,
Senior Software Engineer,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
phone: +94773325954
email: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Chamila De Alwis <ch...@wso2.com>.
Hi,
Is the possibility of upgrading to a newer version of Axis2 available (if
we are using an older version) ?
We might lose the granularity in the responses (currently we use custom
exceptions) if we switch to REST as the protocol between the components
(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" <la...@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 <la...@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: lahirus@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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Lahiru Sandaruwan <la...@wso2.com>.
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 <la...@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: lahirus@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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Udara Liyanage <ud...@wso2.com>.
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?
*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
* Is it a good practice to change return type just for catching exceptions
On Sun, May 10, 2015 at 10:11 AM, Lahiru Sandaruwan <la...@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: lahirus@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
Re: [Discuss] How to handle errors at server side in AS/CC services
Posted by Imesh Gunaratne <im...@apache.org>.
Hi Lahiru,
A great finding!! +1 for fixing this issue with changing the return type to
boolean. As we already know there are quite a lot of limitations in the
Axis2 version we are using today. May be at some point we could move all
our internal web services to REST.
Thanks
On Sun, May 10, 2015 at 10:11 AM, Lahiru Sandaruwan <la...@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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
--
Imesh Gunaratne
Senior Technical Lead, WSO2
Committer & PMC Member, Apache Stratos