java axis web service error
hi,
i hav developed a customer web service. when i try build it gives some
errors. this is my CustomerRPCClient
*CustomerRPCClient :*
package pojo.apache.axis;
>
> import javax.xml.namespace.QName;
>
> import org.apache.axis.AxisFault;
> import org.apache.axis.addressing.EndpointReference;
> import org.apache.axis.client.Options;
> import org.apache.axis.rpc.client.RPCServiceClient;
>
> import pojo.apache.axis.Customer;
>
>
> public class CustomerRPCClient {
>
> public static void main(String[] args1) throws AxisFault {
>
> RPCServiceClient serviceClient = new RPCServiceClient();
>
> Options options = serviceClient.getOptions();
>
> EndpointReference targetEPR = new EndpointReference("
> http://localhost:8080/axis/services/CustomerService";);
>
> options.setTo(targetEPR);
>
> // Setting the customer
> QName opSetCustomer = new QName("http://service.pojo.sample";,
> "setCustomer");
>
> Customer cus = new Customer();
>
> cus.setCid("AAA");
> cus.setName("Ushan");
> cus.setPhone((int)2363765);
> cus.setAddress((int)111, "Kotta Road", "Borella");
> cus.setAge((int)25);
> cus.setBalance((double)25000.00);
>
> Object[] opSetCustomerArgs = new Object[] { cus };
>
> serviceClient.invokeRobust(opSetCustomer, opSetCustomerArgs);
>
>
> // Getting the customer
> QName opGetCustomer = new QName("http://service.pojo.sample";,
> "getCustomer");
>
> Object[] opGetCustomerArgs = new Object[] { };
> Class[] returnTypes = new Class[] { Customer.class };
>
>
> Object[] response = serviceClient.invokeBlocking(opGetCustomer,
> opGetCustomerArgs, returnTypes);
>
> Customer result = (Customer) response[0];
>
> if (result == null) {
> System.out.println("Customer didn't initialize!");
> return;
> }
>
> // Displaying the result
> System.out.println("Customer ID : " +
> result.getCid());
> System.out.println("Customer Name : " +
> result.getName());
> System.out.println("Phone Number : " +
> result.getPhone());
> System.out.println("Address : " +
> result.getAddress());
> System.out.println("Customer's Age: " +
> result.getAge());
> System.out.println("Account Balance : " +
> result.getBalance());
>
> }
> }
>
*
error :*
C:\Documents and Settings\Ushan Adikaram\Desktop\CS\src>javac -d ..\classes
> pojo
> \apache\axis\CustomerRPCClient.java
> pojo\apache\axis\CustomerRPCClient.java:6: package org.apache.axis does not
> exis
> t
> import org.apache.axis.AxisFault;
>^
> pojo\apache\axis\CustomerRPCClient.java:7: package
> org.apache.axis.addressing do
> es not exist
> import org.apache.axis.addressing.EndpointReference;
> ^
> pojo\apache\axis\CustomerRPCClient.java:8: package org.apache.axis.client
> does n
> ot exist
> import org.apache.axis.client.Options;
> ^
> pojo\apache\axis\CustomerRPCClient.java:9: package
> org.apache.axis.rpc.client do
> es not exist
> import org.apache.axis.rpc.client.RPCServiceClient;
> ^
> pojo\apache\axis\CustomerRPCClient.java:16: cannot find symbol
> symbol : class AxisFault
> location: class pojo.apache.axis.CustomerRPCClient
> public static void main(String[] args1) throws AxisFault {
>^
> pojo\apache\axis\CustomerRPCClient.java:18: cannot find symbol
> symbol : class RPCServiceClient
> location: class pojo.apache.axis.CustomerRPCClient
> RPCServiceClient serviceClient = new RPCServiceClient();
> ^
> pojo\apache\axis\CustomerRPCClient.java:18: cannot find symbol
> symbol : class RPCServiceClient
> location: class pojo.apache.axis.CustomerRPCClient
> RPCServiceClient serviceClient = new RPCServiceClient();
> ^
> pojo\apache\axis\CustomerRPCClient.java:20: cannot find symbol
> symbol : class Options
> location: class pojo.apache.axis.CustomerRPCClient
> Options options = serviceClient.getOptions();
> ^
> pojo\apache\axis\CustomerRPCClient.java:22: cannot find symbol
> symbol : class EndpointReference
> location: class pojo.apache.axis.CustomerRPCClient
> EndpointReference targetEPR = new EndpointReference("
> http://localhost:80
> 80/axis/services/CustomerService");
> ^
> pojo\apache\axis\CustomerRPCClient.java:22: cannot find symbol
> symbol : class EndpointReference
> location: class pojo.apache.axis.CustomerRPCClient
> EndpointReference targetEPR = new EndpointReference("
> http://localhost:80
> 80/axis/services/CustomerService");
> ^
> pojo\apache\axis\CustomerRPCClient.java:29: cannot find symbol
> symbol
Web Service error
Hi all,
I created a WSDL file.using java2wsdl and got the following WSDL
(attached for reference). I see the WSDL deployed on
http://localhost:8080/axis/services/Bingo?wsdl.
When I write a client , I get the folllowing error.. What could be the
reason and also , please let me know if the WSDL is created properly... I
have a doubt on the WSDL creation
AxisFault
faultCode: {
*http://schemas.xmlsoap.org/soap/envelope/}Server.userException
*
faultSubcode:
faultString:
*java.lang.reflect.InvocationTargetException*
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}hostname:builds
*
java.lang.reflect.InvocationTargetException
*
at org.apache.axis.message.SOAPFaultBuilder.createFault(
*SOAPFaultBuilder.java:222*)
at org.apache.axis.message.SOAPFaultBuilder.endElement(
*SOAPFaultBuilder.java:129*)
at org.apache.axis.encoding.DeserializationCo
Any help gr8ly appreciated.
Regards,
Sarika
http://xml.apache.org/xml-soap"; xmlns:impl="urn:com.fci.healthcheck.service" xmlns:intf="urn:com.fci.healthcheck.service" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"; xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema";>
http://www.w3.org/2001/XMLSchema";>
http://schemas.xmlsoap.org/soap/encoding/"/>
http://schemas.xmlsoap.org/soap/http"/>
http://schemas.xmlsoap.org/soap/encoding/"; namespace="urn:com.fci.healthcheck.service" use="encoded"/>
http://schemas.xmlsoap.org/soap/encoding/"; namespace="urn:com.fci.healthcheck.service" use="encoded"/>
http://localhost:8080/axis/services/Bingo2"/>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Axis2 web service error
Hi, I created a service archive using eclipse plug-in for service archiving. My project uses a lot of classes in the library and so I included all those libraries when I created my service archive. However, when I load the aar file in the axis2 server, I keep getting the following deployment fault - Error: java.lang.NoClassDefFoundError: com/informatica/metadata/common/core/NamedElement at java.lang.ClassLoader.defineClass1(Native Method) My first thought was that it couldn't locate the jar files. So, I copied all the jar files in the axis/WEB-INF/services/lib folder. It continued to give me the same error, so I copied all the jar files to axis/WEB-INF/lib too. The error message didn't change. Any idea, on what might be causing this error ? Also, I would appreciate if someone could tell me how to directly include all these files in the classpath of axis2, instead of me copying them one by one into the axis2 lib directories. Thanks in advance, -Lokesh
Re: Clients don't get exception thrown out of methods returning void (was: Re: Web service error handling with POJO approach)
Thanks, Anne. Here it is:
https://issues.apache.org/jira/browse/AXIS2-2529
I attached a ZIP of a hacked version of samples/pojo that demonstrates
the problem.
On 4/15/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
Please file a JIRA.
On 4/14/07, John G. Norman <[EMAIL PROTECTED]> wrote:
> Martin,
>
> *** Throw an exception from the method that returns void.
>
> That's what my posting was about: If you throw an exception from a
> method that returns void, ** the client never gets the exception **.
> It will be logged on the server-side.
>
> If you change the method to return something like String (but, again,
> throw an exception from within the method), the client does get the
> exception.
>
> John
>
> On 4/14/07, Martin Gainty <[EMAIL PROTECTED]> wrote:
> > Good Afternoon John-
> >
> > I just deployed the Axis 2.1.1 original pojo sample of AddressBookService
> > without any errors
> >
> > pojo/build/classes/META-INF/services.xml displays
> >
> >
> > POJO: AddressBook Service
> >
> >
> > http://www.w3.org/2004/08/wsdl/in-only";
> >
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
> > http://www.w3.org/2004/08/wsdl/in-out";
> >
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
> >
> > > locked="false">sample.addressbook.service.AddressBookService
> >
> >
> >
> > here is the code for AddressBookService
> >
> > package sample.addressbook.service;
> > public class AddressBookService {
> > private HashMap entries = new HashMap();
> > /*** Add an Entry to the Address Book
> > * @param entry */
> > public void addEntry(Entry entry)
> >{
> > this.entries.put(entry.getName(), entry);
> > }
> >
> > /*** Search an address of a person
> > * @param name the name of the person whose address needs to be found
> > * @return return the address entry of the person.
> > */
> > public Entry findEntry(String name)
> >{
> > return (Entry) this.entries.get(name);
> > }
> > }
> >
> > !--once the service is deployed I can access the service attributes via
> > !--http://localhost:8080/axis2-/axis2-admin/listService
> > !--which displays
> >
> > Service Description: AddressBookService
> > Service Status : Active
> > Engaged modules for the service
> > a.. addressing-1.1 :: Disengage
> >
> > Available operations
> > b.. addEntry
> > Engaged Modules for the Operation
> > a.. addressing-1.1 :: Disengage
> >
> > c.. findEntry
> > Engaged Modules for the Operation
> > a.. addressing-1.1 :: Disengage
> >
> >
> > I'm attempting to understand why you had to change the signatures when
> > services.xml already declares
> > org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver (addEntry method)
> > org.apache.axis2.rpc.receivers.RPCMessageReceiver (findEntry method)
> >
> > ???
> > Martin
> >
> > This email message and any files transmitted with it contain confidential
> > information intended only for the person(s) to whom this email message is
> > addressed. If you have received this email message in error, please notify
> > the sender immediately by telephone or email and destroy the original
> > message without making a copy. Thank you.
> >
> > - Original Message -
> > From: "John G. Norman" <[EMAIL PROTECTED]>
> > To:
> > Sent: Saturday, April 14, 2007 11:12 AM
> > Subject: Clients don't get exception thrown out of methods returning void
> > (was: Re: Web service error handling with POJO approach)
> >
> >
> > > After many hours, I finally traced my problem to an apparent bug.
> > >
> > > (Workaround for the bug at the end.)
> > >
> > > The bug looks a lot like 1277 in Jira, which was a blocker and
> > > resolved for 1.0 (http://issues.apache.org/jira/browse/AXIS2-1277).
> > >
> > > Before I add a bug report, I would appreciate it if someone out there
> > > could reproduce what's below as a sanity check. It's about 10 lines
> > > added to one of the samples.
> > >
> > > Here's the story:
> > >
> > > My POJO-style client wasn't getting exceptions from its POJO-style
> > > service. So I went back to the samp
Re: Clients don't get exception thrown out of methods returning void (was: Re: Web service error handling with POJO approach)
Please file a JIRA.
On 4/14/07, John G. Norman <[EMAIL PROTECTED]> wrote:
Martin,
*** Throw an exception from the method that returns void.
That's what my posting was about: If you throw an exception from a
method that returns void, ** the client never gets the exception **.
It will be logged on the server-side.
If you change the method to return something like String (but, again,
throw an exception from within the method), the client does get the
exception.
John
On 4/14/07, Martin Gainty <[EMAIL PROTECTED]> wrote:
> Good Afternoon John-
>
> I just deployed the Axis 2.1.1 original pojo sample of AddressBookService
> without any errors
>
> pojo/build/classes/META-INF/services.xml displays
>
>
> POJO: AddressBook Service
>
>
> http://www.w3.org/2004/08/wsdl/in-only";
>
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
> http://www.w3.org/2004/08/wsdl/in-out";
>
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
>
> locked="false">sample.addressbook.service.AddressBookService
>
>
>
> here is the code for AddressBookService
>
> package sample.addressbook.service;
> public class AddressBookService {
> private HashMap entries = new HashMap();
> /*** Add an Entry to the Address Book
> * @param entry */
> public void addEntry(Entry entry)
>{
> this.entries.put(entry.getName(), entry);
> }
>
> /*** Search an address of a person
> * @param name the name of the person whose address needs to be found
> * @return return the address entry of the person.
> */
> public Entry findEntry(String name)
>{
> return (Entry) this.entries.get(name);
> }
> }
>
> !--once the service is deployed I can access the service attributes via
> !--http://localhost:8080/axis2-/axis2-admin/listService
> !--which displays
>
> Service Description: AddressBookService
> Service Status : Active
> Engaged modules for the service
> a.. addressing-1.1 :: Disengage
>
> Available operations
> b.. addEntry
> Engaged Modules for the Operation
> a.. addressing-1.1 :: Disengage
>
> c.. findEntry
> Engaged Modules for the Operation
> a.. addressing-1.1 :: Disengage
>
>
> I'm attempting to understand why you had to change the signatures when
> services.xml already declares
> org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver (addEntry method)
> org.apache.axis2.rpc.receivers.RPCMessageReceiver (findEntry method)
>
> ???
> Martin
>
> This email message and any files transmitted with it contain confidential
> information intended only for the person(s) to whom this email message is
> addressed. If you have received this email message in error, please notify
> the sender immediately by telephone or email and destroy the original
> message without making a copy. Thank you.
>
> - Original Message -
> From: "John G. Norman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, April 14, 2007 11:12 AM
> Subject: Clients don't get exception thrown out of methods returning void
> (was: Re: Web service error handling with POJO approach)
>
>
> > After many hours, I finally traced my problem to an apparent bug.
> >
> > (Workaround for the bug at the end.)
> >
> > The bug looks a lot like 1277 in Jira, which was a blocker and
> > resolved for 1.0 (http://issues.apache.org/jira/browse/AXIS2-1277).
> >
> > Before I add a bug report, I would appreciate it if someone out there
> > could reproduce what's below as a sanity check. It's about 10 lines
> > added to one of the samples.
> >
> > Here's the story:
> >
> > My POJO-style client wasn't getting exceptions from its POJO-style
> > service. So I went back to the samples/pojo example, and threw an
> > exception from a method. The client got it. Hmm. I just couldn't
> > figure out what the difference was between my code and the sample.
> > Then I realized that my methods return void.
> >
> > So I added this to AddressBookService.java in samples/pojo, a method
> > returning void, then a second returning String:
> >
> >public void test1(String s) throws Exception {
> > throw new Exception("test1");
> >}
> >
> >public String test2(String s) throws Exception {
> > throw new Exception("test2");
> >}
> >
> > And this to AddressBookADBClient.java:
> >
> >Test1 test1 =
Re: Clients don't get exception thrown out of methods returning void (was: Re: Web service error handling with POJO approach)
Martin,
*** Throw an exception from the method that returns void.
That's what my posting was about: If you throw an exception from a
method that returns void, ** the client never gets the exception **.
It will be logged on the server-side.
If you change the method to return something like String (but, again,
throw an exception from within the method), the client does get the
exception.
John
On 4/14/07, Martin Gainty <[EMAIL PROTECTED]> wrote:
Good Afternoon John-
I just deployed the Axis 2.1.1 original pojo sample of AddressBookService
without any errors
pojo/build/classes/META-INF/services.xml displays
POJO: AddressBook Service
http://www.w3.org/2004/08/wsdl/in-only";
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
http://www.w3.org/2004/08/wsdl/in-out";
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
sample.addressbook.service.AddressBookService
here is the code for AddressBookService
package sample.addressbook.service;
public class AddressBookService {
private HashMap entries = new HashMap();
/*** Add an Entry to the Address Book
* @param entry */
public void addEntry(Entry entry)
{
this.entries.put(entry.getName(), entry);
}
/*** Search an address of a person
* @param name the name of the person whose address needs to be found
* @return return the address entry of the person.
*/
public Entry findEntry(String name)
{
return (Entry) this.entries.get(name);
}
}
!--once the service is deployed I can access the service attributes via
!--http://localhost:8080/axis2-/axis2-admin/listService
!--which displays
Service Description: AddressBookService
Service Status : Active
Engaged modules for the service
a.. addressing-1.1 :: Disengage
Available operations
b.. addEntry
Engaged Modules for the Operation
a.. addressing-1.1 :: Disengage
c.. findEntry
Engaged Modules for the Operation
a.. addressing-1.1 :: Disengage
I'm attempting to understand why you had to change the signatures when
services.xml already declares
org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver (addEntry method)
org.apache.axis2.rpc.receivers.RPCMessageReceiver (findEntry method)
???
Martin
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
- Original Message -
From: "John G. Norman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 14, 2007 11:12 AM
Subject: Clients don't get exception thrown out of methods returning void
(was: Re: Web service error handling with POJO approach)
> After many hours, I finally traced my problem to an apparent bug.
>
> (Workaround for the bug at the end.)
>
> The bug looks a lot like 1277 in Jira, which was a blocker and
> resolved for 1.0 (http://issues.apache.org/jira/browse/AXIS2-1277).
>
> Before I add a bug report, I would appreciate it if someone out there
> could reproduce what's below as a sanity check. It's about 10 lines
> added to one of the samples.
>
> Here's the story:
>
> My POJO-style client wasn't getting exceptions from its POJO-style
> service. So I went back to the samples/pojo example, and threw an
> exception from a method. The client got it. Hmm. I just couldn't
> figure out what the difference was between my code and the sample.
> Then I realized that my methods return void.
>
> So I added this to AddressBookService.java in samples/pojo, a method
> returning void, then a second returning String:
>
>public void test1(String s) throws Exception {
> throw new Exception("test1");
>}
>
>public String test2(String s) throws Exception {
> throw new Exception("test2");
>}
>
> And this to AddressBookADBClient.java:
>
>Test1 test1 = new Test1();
>test1.setParam0("foo");
>stub.test1(test1);
>
>Test2 test2 = new Test2();
>test2.setParam0("bar");
>stub.test2(test2);
>
> Here's a snippet from the server-side log:
>
> Apr 14, 2007 10:55:28 AM
> org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver
> invokeBusinessLogic
> SEVERE: test1
> java.lang.reflect.InvocationTargetException
> Caused by: java.lang.Exception: test1
>at sample.addressbook.service.AddressBookService.test1(Unknown
> Source)
>... 35 more
> Apr 14, 2007 10:55:29 AM
> org.ap
Re: Clients don't get exception thrown out of methods returning void (was: Re: Web service error handling with POJO approach)
Good Afternoon John-
I just deployed the Axis 2.1.1 original pojo sample of AddressBookService
without any errors
pojo/build/classes/META-INF/services.xml displays
POJO: AddressBook Service
http://www.w3.org/2004/08/wsdl/in-only";
class="org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver"/>
http://www.w3.org/2004/08/wsdl/in-out";
class="org.apache.axis2.rpc.receivers.RPCMessageReceiver"/>
locked="false">sample.addressbook.service.AddressBookService
here is the code for AddressBookService
package sample.addressbook.service;
public class AddressBookService {
private HashMap entries = new HashMap();
/*** Add an Entry to the Address Book
* @param entry */
public void addEntry(Entry entry)
{
this.entries.put(entry.getName(), entry);
}
/*** Search an address of a person
* @param name the name of the person whose address needs to be found
* @return return the address entry of the person.
*/
public Entry findEntry(String name)
{
return (Entry) this.entries.get(name);
}
}
!--once the service is deployed I can access the service attributes via
!--http://localhost:8080/axis2-/axis2-admin/listService
!--which displays
Service Description: AddressBookService
Service Status : Active
Engaged modules for the service
a.. addressing-1.1 :: Disengage
Available operations
b.. addEntry
Engaged Modules for the Operation
a.. addressing-1.1 :: Disengage
c.. findEntry
Engaged Modules for the Operation
a.. addressing-1.1 :: Disengage
I'm attempting to understand why you had to change the signatures when
services.xml already declares
org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver (addEntry method)
org.apache.axis2.rpc.receivers.RPCMessageReceiver (findEntry method)
???
Martin
This email message and any files transmitted with it contain confidential
information intended only for the person(s) to whom this email message is
addressed. If you have received this email message in error, please notify
the sender immediately by telephone or email and destroy the original
message without making a copy. Thank you.
- Original Message -
From: "John G. Norman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, April 14, 2007 11:12 AM
Subject: Clients don't get exception thrown out of methods returning void
(was: Re: Web service error handling with POJO approach)
After many hours, I finally traced my problem to an apparent bug.
(Workaround for the bug at the end.)
The bug looks a lot like 1277 in Jira, which was a blocker and
resolved for 1.0 (http://issues.apache.org/jira/browse/AXIS2-1277).
Before I add a bug report, I would appreciate it if someone out there
could reproduce what's below as a sanity check. It's about 10 lines
added to one of the samples.
Here's the story:
My POJO-style client wasn't getting exceptions from its POJO-style
service. So I went back to the samples/pojo example, and threw an
exception from a method. The client got it. Hmm. I just couldn't
figure out what the difference was between my code and the sample.
Then I realized that my methods return void.
So I added this to AddressBookService.java in samples/pojo, a method
returning void, then a second returning String:
public void test1(String s) throws Exception {
throw new Exception("test1");
}
public String test2(String s) throws Exception {
throw new Exception("test2");
}
And this to AddressBookADBClient.java:
Test1 test1 = new Test1();
test1.setParam0("foo");
stub.test1(test1);
Test2 test2 = new Test2();
test2.setParam0("bar");
stub.test2(test2);
Here's a snippet from the server-side log:
Apr 14, 2007 10:55:28 AM
org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver
invokeBusinessLogic
SEVERE: test1
java.lang.reflect.InvocationTargetException
Caused by: java.lang.Exception: test1
at sample.addressbook.service.AddressBookService.test1(Unknown
Source)
... 35 more
Apr 14, 2007 10:55:29 AM
org.apache.axis2.rpc.receivers.RPCMessageReceiver invokeBusinessLogic
SEVERE: test2
java.lang.reflect.InvocationTargetException
Caused by: java.lang.Exception: test2
at sample.addressbook.service.AddressBookService.test2(Unknown
Source)
... 35 more
As you can see, both exceptions are thrown.
Now here's the client (NOTICE: No evidence of an exception from the
test1 method):
adb.client.run:
[java] Name :Abby Cadabby
[java] Street :Sesame Street
[java] City :Sesame City
[java] State :Sesame State
[java] Postal Code :1
[java] org.apache.axis2.AxisFault: test2
[java] at
org.apache.axis2.description.OutInAxisOperationClient.send(O
Clients don't get exception thrown out of methods returning void (was: Re: Web service error handling with POJO approach)
After many hours, I finally traced my problem to an apparent bug.
(Workaround for the bug at the end.)
The bug looks a lot like 1277 in Jira, which was a blocker and
resolved for 1.0 (http://issues.apache.org/jira/browse/AXIS2-1277).
Before I add a bug report, I would appreciate it if someone out there
could reproduce what's below as a sanity check. It's about 10 lines
added to one of the samples.
Here's the story:
My POJO-style client wasn't getting exceptions from its POJO-style
service. So I went back to the samples/pojo example, and threw an
exception from a method. The client got it. Hmm. I just couldn't
figure out what the difference was between my code and the sample.
Then I realized that my methods return void.
So I added this to AddressBookService.java in samples/pojo, a method
returning void, then a second returning String:
public void test1(String s) throws Exception {
throw new Exception("test1");
}
public String test2(String s) throws Exception {
throw new Exception("test2");
}
And this to AddressBookADBClient.java:
Test1 test1 = new Test1();
test1.setParam0("foo");
stub.test1(test1);
Test2 test2 = new Test2();
test2.setParam0("bar");
stub.test2(test2);
Here's a snippet from the server-side log:
Apr 14, 2007 10:55:28 AM
org.apache.axis2.rpc.receivers.RPCInOnlyMessageReceiver
invokeBusinessLogic
SEVERE: test1
java.lang.reflect.InvocationTargetException
Caused by: java.lang.Exception: test1
at sample.addressbook.service.AddressBookService.test1(Unknown Source)
... 35 more
Apr 14, 2007 10:55:29 AM
org.apache.axis2.rpc.receivers.RPCMessageReceiver invokeBusinessLogic
SEVERE: test2
java.lang.reflect.InvocationTargetException
Caused by: java.lang.Exception: test2
at sample.addressbook.service.AddressBookService.test2(Unknown Source)
... 35 more
As you can see, both exceptions are thrown.
Now here's the client (NOTICE: No evidence of an exception from the
test1 method):
adb.client.run:
[java] Name :Abby Cadabby
[java] Street :Sesame Street
[java] City :Sesame City
[java] State :Sesame State
[java] Postal Code :1
[java] org.apache.axis2.AxisFault: test2
[java] at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.jav
a:271)
[java] at
org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.
java:202)
[java] at
sample.addressbook.stub.AddressBookServiceStub.test2(Unknown Source)
So I guess that the workaround is that I'll have to have all of my
methods return something: Perhaps a String, or maybe I'll create a
JavaBean class called Nothing. Or maybe even Void with a capital V.
This is a really awful bug.
On 4/10/07, John G. Norman <[EMAIL PROTECTED]> wrote:
With a POJO Service:
I have now tried the strategy here:
http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/util/FaultThrowingService.java?view=markup
Still not seeing the exception on the client that calls the service .
. . Still getting:
> FaultReason; nested exception is:
> java.lang.Exception: This is a test Exception
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> [much deleted]
>
> Caused by: org.apache.axis2.AxisFault: FaultReason; nested exception is:
> java.lang.Exception: This is a test Exception
> at com.myco.Service.test(Service.java:45)
> ... 48 more
> Caused by: java.lang.Exception: This is a test Exception
> ... 49 more
> DEBUG 16:24:37,843 org.apache.axis2.AxisFault: FaultReason; nested
> exception is:
> java.lang.Exception: This is a test Exception
> DEBUG 16:24:37,843 isReplyRedirected: FaultTo is null. Returning
> isReplyRedirected
> DEBUG 16:24:37,843 isReplyRedirected: ReplyTo is null. Returning false
>
On 4/9/07, John G. Norman <[EMAIL PROTECTED]> wrote:
> Hi all.
>
> This is a great topic -- how to manage exceptions for services built
> on POJOs. If it is as easy as the link Anne Manes provided
> (http://wso2.org/library/171) then throwing exceptions might well be
> included in the main Axis2 docs at
> http://ws.apache.org/axis2/1_1_1/pojoguide.html).
>
> But I just tried throwing an exception out of a POJO's method (the
> basis for a service as described here:
> http://ws.apache.org/axis2/1_1_1/pojoguide.html), and the exception
> doesn't seem to make it back to the client.
>
> Does the QName need to match one of the faults defined in the client stub?
>
> In any case, the code looks like this:
>
> public void test() throws AxisFault {
> throw n
Re: Web service error handling with POJO approach
With a POJO Service:
I have now tried the strategy here:
http://svn.apache.org/viewvc/webservices/axis2/trunk/java/modules/integration/test/org/apache/axis2/engine/util/FaultThrowingService.java?view=markup
Still not seeing the exception on the client that calls the service .
. . Still getting:
FaultReason; nested exception is:
java.lang.Exception: This is a test Exception
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
[much deleted]
Caused by: org.apache.axis2.AxisFault: FaultReason; nested exception is:
java.lang.Exception: This is a test Exception
at com.myco.Service.test(Service.java:45)
... 48 more
Caused by: java.lang.Exception: This is a test Exception
... 49 more
DEBUG 16:24:37,843 org.apache.axis2.AxisFault: FaultReason; nested
exception is:
java.lang.Exception: This is a test Exception
DEBUG 16:24:37,843 isReplyRedirected: FaultTo is null. Returning
isReplyRedirected
DEBUG 16:24:37,843 isReplyRedirected: ReplyTo is null. Returning false
On 4/9/07, John G. Norman <[EMAIL PROTECTED]> wrote:
Hi all.
This is a great topic -- how to manage exceptions for services built
on POJOs. If it is as easy as the link Anne Manes provided
(http://wso2.org/library/171) then throwing exceptions might well be
included in the main Axis2 docs at
http://ws.apache.org/axis2/1_1_1/pojoguide.html).
But I just tried throwing an exception out of a POJO's method (the
basis for a service as described here:
http://ws.apache.org/axis2/1_1_1/pojoguide.html), and the exception
doesn't seem to make it back to the client.
Does the QName need to match one of the faults defined in the client stub?
In any case, the code looks like this:
public void test() throws AxisFault {
throw new AxisFault(new QName("http://test.org";, "FaultCode",
"test"), "FaultReason", new Exception("This is a test Exception"));
}
On the server, the trace looks like this:
FaultReason; nested exception is:
java.lang.Exception: This is a test Exception
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
[much deleted]
Caused by: org.apache.axis2.AxisFault: FaultReason; nested exception is:
java.lang.Exception: This is a test Exception
at com.myco.Service.test(Service.java:45)
... 48 more
Caused by: java.lang.Exception: This is a test Exception
... 49 more
DEBUG 16:24:37,843 org.apache.axis2.AxisFault: FaultReason; nested
exception is:
java.lang.Exception: This is a test Exception
DEBUG 16:24:37,843 isReplyRedirected: FaultTo is null. Returning
isReplyRedirected
DEBUG 16:24:37,843 isReplyRedirected: ReplyTo is null. Returning false
On 4/3/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> See http://wso2.org/library/171.
>
> On 4/3/07, Chan, Herman <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > Hi all:
> >
> >
> >
> > I am relatively new to Axis 2 and web services in general, so please bear
> > with me if I ask any stupid questions.
> >
> >
> >
> > I am writing a very simple web service that would return a list of
> > directories on a server. However, if certain directories does not exists,
> > I'd like a throw an error back to the calling client.
> >
> >
> >
> > I am using the POJO approach to create web services using axis2, so is it
> > good enough for me to throw a plain Exception or do I have to do more? What
> > is the best practice in doing error handling in web services?
> >
> >
> >
> > Thanks in advance.
> >
> >
> >
> > Herman Chan
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web service error handling with POJO approach
Hi all.
This is a great topic -- how to manage exceptions for services built
on POJOs. If it is as easy as the link Anne Manes provided
(http://wso2.org/library/171) then throwing exceptions might well be
included in the main Axis2 docs at
http://ws.apache.org/axis2/1_1_1/pojoguide.html).
But I just tried throwing an exception out of a POJO's method (the
basis for a service as described here:
http://ws.apache.org/axis2/1_1_1/pojoguide.html), and the exception
doesn't seem to make it back to the client.
Does the QName need to match one of the faults defined in the client stub?
In any case, the code looks like this:
public void test() throws AxisFault {
throw new AxisFault(new QName("http://test.org";, "FaultCode",
"test"), "FaultReason", new Exception("This is a test Exception"));
}
On the server, the trace looks like this:
FaultReason; nested exception is:
java.lang.Exception: This is a test Exception
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
[much deleted]
Caused by: org.apache.axis2.AxisFault: FaultReason; nested exception is:
java.lang.Exception: This is a test Exception
at com.myco.Service.test(Service.java:45)
... 48 more
Caused by: java.lang.Exception: This is a test Exception
... 49 more
DEBUG 16:24:37,843 org.apache.axis2.AxisFault: FaultReason; nested
exception is:
java.lang.Exception: This is a test Exception
DEBUG 16:24:37,843 isReplyRedirected: FaultTo is null. Returning
isReplyRedirected
DEBUG 16:24:37,843 isReplyRedirected: ReplyTo is null. Returning false
On 4/3/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
See http://wso2.org/library/171.
On 4/3/07, Chan, Herman <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Hi all:
>
>
>
> I am relatively new to Axis 2 and web services in general, so please bear
> with me if I ask any stupid questions.
>
>
>
> I am writing a very simple web service that would return a list of
> directories on a server. However, if certain directories does not exists,
> I'd like a throw an error back to the calling client.
>
>
>
> I am using the POJO approach to create web services using axis2, so is it
> good enough for me to throw a plain Exception or do I have to do more? What
> is the best practice in doing error handling in web services?
>
>
>
> Thanks in advance.
>
>
>
> Herman Chan
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Web service error handling with POJO approach
See http://wso2.org/library/171. On 4/3/07, Chan, Herman <[EMAIL PROTECTED]> wrote: Hi all: I am relatively new to Axis 2 and web services in general, so please bear with me if I ask any stupid questions. I am writing a very simple web service that would return a list of directories on a server. However, if certain directories does not exists, I'd like a throw an error back to the calling client. I am using the POJO approach to create web services using axis2, so is it good enough for me to throw a plain Exception or do I have to do more? What is the best practice in doing error handling in web services? Thanks in advance. Herman Chan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Web service error handling with POJO approach
Hi all: I am relatively new to Axis 2 and web services in general, so please bear with me if I ask any stupid questions. I am writing a very simple web service that would return a list of directories on a server. However, if certain directories does not exists, I'd like a throw an error back to the calling client. I am using the POJO approach to create web services using axis2, so is it good enough for me to throw a plain Exception or do I have to do more? What is the best practice in doing error handling in web services? Thanks in advance. Herman Chan
Web Service Error
Hi,
I am trying to call
a Web Service from a Message Listener (from within it's onMessage() method)
class.
The Message Listener
(the class is attached with this mail) keeps listening to a queue and once a JMS
message is received in the queue, it gets the JMS message and extracts the SOAP
request which resides within the JMS payload. Once this SOAP request is
got, I call the Web Service by creating an AxisServer instance and a
MesageContext bounded to this AxisServer. The SOAP request is placed
as a request message in the MessageContext and the I set the target Web
Service by calling
MessageContext.setTargetService(). After this the Web
Service is invoked by calling the engine.invoke() method.
At this point, the
application throws up an malformed URL exception which I am unable to decipher.
Also, I have tested to see if such a Service exists and is running by using the
following lines of code.
SOAPService soapService =
engine.getService("MOVIEServer"); System.out.println("\nThe
service running is
"+soapService.isRunning()+"\n");
The application
shows the service above (MOVIEServer) to be up and
running.
The error message is
pasted below:-
--> 06-22-06
11:59:44 ERROR [ORB-Worker-1] ResourceHandler: An unexpected erroroccured
during processing of a request.java.lang.RuntimeException: Value of Axis
transport.url MessageContext propertyis not a valid
URL. at
org.apache.ws.resource.handler.axis.AxisResourceContext.getServiceURL(AxisResourceContext.java:68)
at
org.apache.ws.resource.impl.ResourceContextImpl.extractFields(ResourceContextImpl.java:342)
at
org.apache.ws.resource.impl.ResourceContextImpl.(ResourceContextImpl.java:73)
at
org.apache.ws.resource.handler.axis.AxisResourceContext.(AxisResourceContext.java:42)
at
org.apache.ws.util.platform.axis.AxisJaxRpcPlatform.createResourceContext(AxisJaxRpcPlatform.java:92)
at
org.apache.ws.resource.handler.ResourceHandler.handleRequest(ResourceHandler.java:135)
at
org.apache.ws.resource.handler.axis.ResourceProvider.invoke(ResourceProvider.java:209)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at
org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at
org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at
org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453)
at
org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
at
org.apache.ws.resource.example.JMSListenerToClient.onMessage(JMSListenerToClient.java:125)
at
org.exolab.jms.client.JmsMessageConsumer.onMessage(JmsMessageConsumer.java:254)
at
org.exolab.jms.client.JmsSession.onMessage(JmsSession.java:1023)
at
org.exolab.jms.client.net.JmsSessionStubImpl.onMessage(JmsSessionStubImpl.java:478)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
java.lang.reflect.Method.invoke(Method.java:324)
at
org.exolab.jms.net.orb.DefaultORB$Handler.invoke(DefaultORB.java:553)
at
org.exolab.jms.net.orb.DefaultORB$1.run(DefaultORB.java:511)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
Source) at
java.lang.Thread.run(Thread.java:534)Caused by:
java.net.MalformedURLException at
java.net.URL.(URL.java:571)
at
java.net.URL.(URL.java:434)
at
java.net.URL.(URL.java:383)
at
org.apache.ws.resource.handler.axis.AxisResourceContext.getServiceURL(AxisResourceContext.java:64)
... 23 moreAxisFault faultCode:
{http://schemas.xmlsoap.org/soap/envelope/}Server faultSubcode: faultString:
Internal server error
occurred. faultActor: faultNode: faultDetail:
Internal server
error occurred. at
org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
at
org.apache.ws.resource.handler.axis.ResourceProvider.invoke(ResourceProvider.java:214)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at
org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at
org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at
org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:453)
at
org.apache.axis.server.AxisServer.invoke(AxisServer.java:281)
at
org.apache.ws.resource.example.JMSListenerToClient.onMessage(JMSListenerToClient.java:125)
at
org.exolab.jms.client.JmsMessageConsumer.onMessage(JmsMessageConsumer.java:254)
at
org.exolab.jms.client.JmsSession.onMessage(JmsSession.java:1023)
at
org.exolab.jms.client.net.JmsSessionStubImpl.onMessage(JmsSessionStubImpl.java:478)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method
Re: web service error handling design issue
I excluded "being ridiculously wasteful or using poorly designed algorithms". Of course, we need to be careful but not in the way we used to fret over optimal coding. When specifying an for-loop counter, how many people load the size of an ArrayList into a local variable rather than call size() each iteration (I do but most people don't). - Original Message - From: "Dan Armbrust" <[EMAIL PROTECTED]> To: Sent: Thursday, June 02, 2005 5:47 PM Subject: Re: web service error handling design issue > > > > > >programmers no longer need to worry about performance. In fact, we stopped > >worrying about performance once we abandoned C++ for Java! > > > > Speak for yourself... Maybe you work in a world where the datasets are > small, and hardware budgets grow quickly > > I remember digging into a third party package that we were using - they > had recently ported from c to java, and the performance of the new > version sucked on certain operations. Examination of the code revealed > that there was one method that got its result by opening a random file > reader on a 200K file, and finding the appropriate bits. The algorithm > called this method several hundred times per operation. A simple change > to a hashtable based approach with a one-time read of the file resulted > in an operation that ran about 1000 times faster. Multiple that by the > 500,000,000 times I needed to call that method, and we start talking > years instead of hours to process the same data > > Dan > > > > >
Re: web service error handling design issue
programmers no longer need to worry about performance. In fact, we stopped worrying about performance once we abandoned C++ for Java! Speak for yourself... Maybe you work in a world where the datasets are small, and hardware budgets grow quickly I remember digging into a third party package that we were using - they had recently ported from c to java, and the performance of the new version sucked on certain operations. Examination of the code revealed that there was one method that got its result by opening a random file reader on a 200K file, and finding the appropriate bits. The algorithm called this method several hundred times per operation. A simple change to a hashtable based approach with a one-time read of the file resulted in an operation that ran about 1000 times faster. Multiple that by the 500,000,000 times I needed to call that method, and we start talking years instead of hours to process the same data Dan
Re: web service error handling design issue
Rather than obfuscate, extra wrapped exceptions should add clarity. It is not expensive to add exceptions nor is there any benefit to handling exceptions as quickly as possible. Don't get exceptions confused with system interrupts. Once an error has occurred, we are no longer concerned with performance but with proper handling of the condition. Furthermore, unless we are being ridiculously wasteful or using poorly designed algorithms, performance improvements are down to hardware these days. With 16-core Opteron systems at affordable prices and RAM measured in tens of GB, programmers no longer need to worry about performance. In fact, we stopped worrying about performance once we abandoned C++ for Java! Jeff - Original Message - From: "James Taylor" <[EMAIL PROTECTED]> To: Sent: Thursday, June 02, 2005 4:39 PM Subject: Re: web service error handling design issue Sure there's different fixes for different situations but at the end of the day is it not better to deal with the exception as quickly as possible so it doesn't get obfuscated in too many extra wrapped exceptions. Also is it not "expensive", to a degree, to create exceptions? By this I'm wondering that is it not better to try and lessen the overhead on resources on the server. Quoting Jeff <[EMAIL PROTECTED]>: > I agree entirely. I took it as read that error conditions in Java are known > as exceptions :-) > > > Jeff > > > > - Original Message - > From: "Ebert, Chris" <[EMAIL PROTECTED]> > To: > Sent: Thursday, June 02, 2005 1:36 PM > Subject: RE: web service error handling design issue > > > > A (hopefully short) two cents: > > 1) Usually, I prefer to propagate exceptions rather than error codes. > Exceptions really can make application flow simpler. I agree that > 'cooking' the exception is good: the topmost layer that has an > additional useful detail should add it; also, it's often nice to wrap an > exception to provide a consitant interface (wrap an SQLException in a > FooSubsystemException so different implementations can use a database, a > file system, etc.) Error codes are good when the alternate behaviour > isn't really 'exceptional' -- happens, say, 30+% of the time anyway. > 2) That said, when passing exceptions -- particularly chained ones -- > over a remote interface you want to create an exception class > specifically for the interface and only give it basic types as fields -- > no chained exceptions here. This is because you don't want to have all > the server exceptions in the client jar. Axis handles this somewhat > gracefully (you get a null): RMI throws it's own exception if a class > isn't available upon deserialization. This lets the client recognise a > server fault, get some information back about it and decide what to do. > > Hope that was helpful :) > > Chris > > > > -Original Message- > From: Jeff [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 02, 2005 8:41 AM > To: axis-user@ws.apache.org > Subject: Re: web service error handling design issue > > Life is never that simple, James! Academics are prone to produce bland > generalizations and are notorious for being out of touch with reality, > though I suspect that this is due to a few loonies giving the rest a bad > name! Clearly, most academics do a great deal of invaluable work for > which they have my deepest gratitude. > > I once heard that a university professor who claimed that it wasn't > possible to write more than 10 lines of fully debugged code per day. > I've been developing software for 25 years and if my output was anything > like that I'd have gone broke years ago! Only a few months ago at a Java > Users Group meeting I overheard an academic stating with conviction that > "If you have to use a case statement then you didn't do your OOD > properly." -- yeah, right...cretin. > > To answer your question: in any software system, at any point between > where an error occurs and where the outer-most calling code needs to > know about the error, it is potentially appropriate to cook the error. > In many circumstances it is inappropriate for calling code to know the > simple, raw reason why an error occurs. For example, suppose that during > some web service method call a required file was discovered to be absent > from its expected location on a disk. Should you tell the web service > client about this? Most likely not, because that piece of information is > unlikely to be meaningful to the client. Instead, code much closer to > error needs to figure out the consequences and throw an interpretation > up the chain where other code might be able to do something to fix the
Re: web service error handling design issue
Sure there's different fixes for different situations but at the end of the day is it not better to deal with the exception as quickly as possible so it doesn't get obfuscated in too many extra wrapped exceptions. Also is it not "expensive", to a degree, to create exceptions? By this I'm wondering that is it not better to try and lessen the overhead on resources on the server. Quoting Jeff <[EMAIL PROTECTED]>: > I agree entirely. I took it as read that error conditions in Java are known > as exceptions :-) > > > Jeff > > > > - Original Message - > From: "Ebert, Chris" <[EMAIL PROTECTED]> > To: > Sent: Thursday, June 02, 2005 1:36 PM > Subject: RE: web service error handling design issue > > > > A (hopefully short) two cents: > > 1) Usually, I prefer to propagate exceptions rather than error codes. > Exceptions really can make application flow simpler. I agree that > 'cooking' the exception is good: the topmost layer that has an > additional useful detail should add it; also, it's often nice to wrap an > exception to provide a consitant interface (wrap an SQLException in a > FooSubsystemException so different implementations can use a database, a > file system, etc.) Error codes are good when the alternate behaviour > isn't really 'exceptional' -- happens, say, 30+% of the time anyway. > 2) That said, when passing exceptions -- particularly chained ones -- > over a remote interface you want to create an exception class > specifically for the interface and only give it basic types as fields -- > no chained exceptions here. This is because you don't want to have all > the server exceptions in the client jar. Axis handles this somewhat > gracefully (you get a null): RMI throws it's own exception if a class > isn't available upon deserialization. This lets the client recognise a > server fault, get some information back about it and decide what to do. > > Hope that was helpful :) > > Chris > > > > -Original Message- > From: Jeff [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 02, 2005 8:41 AM > To: axis-user@ws.apache.org > Subject: Re: web service error handling design issue > > Life is never that simple, James! Academics are prone to produce bland > generalizations and are notorious for being out of touch with reality, > though I suspect that this is due to a few loonies giving the rest a bad > name! Clearly, most academics do a great deal of invaluable work for > which they have my deepest gratitude. > > I once heard that a university professor who claimed that it wasn't > possible to write more than 10 lines of fully debugged code per day. > I've been developing software for 25 years and if my output was anything > like that I'd have gone broke years ago! Only a few months ago at a Java > Users Group meeting I overheard an academic stating with conviction that > "If you have to use a case statement then you didn't do your OOD > properly." -- yeah, right...cretin. > > To answer your question: in any software system, at any point between > where an error occurs and where the outer-most calling code needs to > know about the error, it is potentially appropriate to cook the error. > In many circumstances it is inappropriate for calling code to know the > simple, raw reason why an error occurs. For example, suppose that during > some web service method call a required file was discovered to be absent > from its expected location on a disk. Should you tell the web service > client about this? Most likely not, because that piece of information is > unlikely to be meaningful to the client. Instead, code much closer to > error needs to figure out the consequences and throw an interpretation > up the chain where other code might be able to do something to fix the > problem (e.g. create a new file from default values and retry) or to > rethrow a more intelligible error. > > Unfortunately, cooking errors is something that often doesn't happen > because too many programmers have higher priorities and finite > deadlines. How many times have you seen a ClassCastException and > wondered which class the code was attempting to cast to? One poorly > handled error can result in a great deal of wasted time, collectively > over thousands of people. > > Also, please note that there are many types of error and you need to be > aware that during software development we see errors (that tend to be > uncooked) that arise through flaws in the logic of the software and will > go away once the code has been debugged but, as an aid to development, > we might want to cook them if they are not immediately resolvable. As I >
Re: web service error handling design issue
I agree entirely. I took it as read that error conditions in Java are known as exceptions :-) Jeff - Original Message - From: "Ebert, Chris" <[EMAIL PROTECTED]> To: Sent: Thursday, June 02, 2005 1:36 PM Subject: RE: web service error handling design issue A (hopefully short) two cents: 1) Usually, I prefer to propagate exceptions rather than error codes. Exceptions really can make application flow simpler. I agree that 'cooking' the exception is good: the topmost layer that has an additional useful detail should add it; also, it's often nice to wrap an exception to provide a consitant interface (wrap an SQLException in a FooSubsystemException so different implementations can use a database, a file system, etc.) Error codes are good when the alternate behaviour isn't really 'exceptional' -- happens, say, 30+% of the time anyway. 2) That said, when passing exceptions -- particularly chained ones -- over a remote interface you want to create an exception class specifically for the interface and only give it basic types as fields -- no chained exceptions here. This is because you don't want to have all the server exceptions in the client jar. Axis handles this somewhat gracefully (you get a null): RMI throws it's own exception if a class isn't available upon deserialization. This lets the client recognise a server fault, get some information back about it and decide what to do. Hope that was helpful :) Chris -Original Message- From: Jeff [mailto:[EMAIL PROTECTED] Sent: Thursday, June 02, 2005 8:41 AM To: axis-user@ws.apache.org Subject: Re: web service error handling design issue Life is never that simple, James! Academics are prone to produce bland generalizations and are notorious for being out of touch with reality, though I suspect that this is due to a few loonies giving the rest a bad name! Clearly, most academics do a great deal of invaluable work for which they have my deepest gratitude. I once heard that a university professor who claimed that it wasn't possible to write more than 10 lines of fully debugged code per day. I've been developing software for 25 years and if my output was anything like that I'd have gone broke years ago! Only a few months ago at a Java Users Group meeting I overheard an academic stating with conviction that "If you have to use a case statement then you didn't do your OOD properly." -- yeah, right...cretin. To answer your question: in any software system, at any point between where an error occurs and where the outer-most calling code needs to know about the error, it is potentially appropriate to cook the error. In many circumstances it is inappropriate for calling code to know the simple, raw reason why an error occurs. For example, suppose that during some web service method call a required file was discovered to be absent from its expected location on a disk. Should you tell the web service client about this? Most likely not, because that piece of information is unlikely to be meaningful to the client. Instead, code much closer to error needs to figure out the consequences and throw an interpretation up the chain where other code might be able to do something to fix the problem (e.g. create a new file from default values and retry) or to rethrow a more intelligible error. Unfortunately, cooking errors is something that often doesn't happen because too many programmers have higher priorities and finite deadlines. How many times have you seen a ClassCastException and wondered which class the code was attempting to cast to? One poorly handled error can result in a great deal of wasted time, collectively over thousands of people. Also, please note that there are many types of error and you need to be aware that during software development we see errors (that tend to be uncooked) that arise through flaws in the logic of the software and will go away once the code has been debugged but, as an aid to development, we might want to cook them if they are not immediately resolvable. As I said, reality is rarely simple, at least not when human beings are involved. BTW, this is not a design issue, it's about writing good software. Jeff Between the question and the answer, all too often, lies pure hell - Original Message ----- From: "James Taylor" <[EMAIL PROTECTED]> To: Sent: Thursday, June 02, 2005 10:22 AM Subject: web service error handling design issue Hey, another design issue on a different note. In our college course we a told to propogate error up to the top layer/controller and deal with them appropriately. What's the best way to deal with errors in the case of web services? Should I catch the exception and return an appropriate fault node/code and deal with this in the client code or catch the error at the service provider top level and return an appropriate explanat
RE: web service error handling design issue
A (hopefully short) two cents: 1) Usually, I prefer to propagate exceptions rather than error codes. Exceptions really can make application flow simpler. I agree that 'cooking' the exception is good: the topmost layer that has an additional useful detail should add it; also, it's often nice to wrap an exception to provide a consitant interface (wrap an SQLException in a FooSubsystemException so different implementations can use a database, a file system, etc.) Error codes are good when the alternate behaviour isn't really 'exceptional' -- happens, say, 30+% of the time anyway. 2) That said, when passing exceptions -- particularly chained ones -- over a remote interface you want to create an exception class specifically for the interface and only give it basic types as fields -- no chained exceptions here. This is because you don't want to have all the server exceptions in the client jar. Axis handles this somewhat gracefully (you get a null): RMI throws it's own exception if a class isn't available upon deserialization. This lets the client recognise a server fault, get some information back about it and decide what to do. Hope that was helpful :) Chris -Original Message- From: Jeff [mailto:[EMAIL PROTECTED] Sent: Thursday, June 02, 2005 8:41 AM To: axis-user@ws.apache.org Subject: Re: web service error handling design issue Life is never that simple, James! Academics are prone to produce bland generalizations and are notorious for being out of touch with reality, though I suspect that this is due to a few loonies giving the rest a bad name! Clearly, most academics do a great deal of invaluable work for which they have my deepest gratitude. I once heard that a university professor who claimed that it wasn't possible to write more than 10 lines of fully debugged code per day. I've been developing software for 25 years and if my output was anything like that I'd have gone broke years ago! Only a few months ago at a Java Users Group meeting I overheard an academic stating with conviction that "If you have to use a case statement then you didn't do your OOD properly." -- yeah, right...cretin. To answer your question: in any software system, at any point between where an error occurs and where the outer-most calling code needs to know about the error, it is potentially appropriate to cook the error. In many circumstances it is inappropriate for calling code to know the simple, raw reason why an error occurs. For example, suppose that during some web service method call a required file was discovered to be absent from its expected location on a disk. Should you tell the web service client about this? Most likely not, because that piece of information is unlikely to be meaningful to the client. Instead, code much closer to error needs to figure out the consequences and throw an interpretation up the chain where other code might be able to do something to fix the problem (e.g. create a new file from default values and retry) or to rethrow a more intelligible error. Unfortunately, cooking errors is something that often doesn't happen because too many programmers have higher priorities and finite deadlines. How many times have you seen a ClassCastException and wondered which class the code was attempting to cast to? One poorly handled error can result in a great deal of wasted time, collectively over thousands of people. Also, please note that there are many types of error and you need to be aware that during software development we see errors (that tend to be uncooked) that arise through flaws in the logic of the software and will go away once the code has been debugged but, as an aid to development, we might want to cook them if they are not immediately resolvable. As I said, reality is rarely simple, at least not when human beings are involved. BTW, this is not a design issue, it's about writing good software. Jeff Between the question and the answer, all too often, lies pure hell - Original Message - From: "James Taylor" <[EMAIL PROTECTED]> To: Sent: Thursday, June 02, 2005 10:22 AM Subject: web service error handling design issue Hey, another design issue on a different note. In our college course we a told to propogate error up to the top layer/controller and deal with them appropriately. What's the best way to deal with errors in the case of web services? Should I catch the exception and return an appropriate fault node/code and deal with this in the client code or catch the error at the service provider top level and return an appropriate explanation? Just looking for ideas and what way is it done in industry. Thanks to anyone that gives my the time to answer, James. -- Between the question and the answer lies free will
Re: web service error handling design issue
Life is never that simple, James! Academics are prone to produce bland generalizations and are notorious for being out of touch with reality, though I suspect that this is due to a few loonies giving the rest a bad name! Clearly, most academics do a great deal of invaluable work for which they have my deepest gratitude. I once heard that a university professor who claimed that it wasn't possible to write more than 10 lines of fully debugged code per day. I've been developing software for 25 years and if my output was anything like that I'd have gone broke years ago! Only a few months ago at a Java Users Group meeting I overheard an academic stating with conviction that "If you have to use a case statement then you didn't do your OOD properly." -- yeah, right...cretin. To answer your question: in any software system, at any point between where an error occurs and where the outer-most calling code needs to know about the error, it is potentially appropriate to cook the error. In many circumstances it is inappropriate for calling code to know the simple, raw reason why an error occurs. For example, suppose that during some web service method call a required file was discovered to be absent from its expected location on a disk. Should you tell the web service client about this? Most likely not, because that piece of information is unlikely to be meaningful to the client. Instead, code much closer to error needs to figure out the consequences and throw an interpretation up the chain where other code might be able to do something to fix the problem (e.g. create a new file from default values and retry) or to rethrow a more intelligible error. Unfortunately, cooking errors is something that often doesn't happen because too many programmers have higher priorities and finite deadlines. How many times have you seen a ClassCastException and wondered which class the code was attempting to cast to? One poorly handled error can result in a great deal of wasted time, collectively over thousands of people. Also, please note that there are many types of error and you need to be aware that during software development we see errors (that tend to be uncooked) that arise through flaws in the logic of the software and will go away once the code has been debugged but, as an aid to development, we might want to cook them if they are not immediately resolvable. As I said, reality is rarely simple, at least not when human beings are involved. BTW, this is not a design issue, it's about writing good software. Jeff Between the question and the answer, all too often, lies pure hell - Original Message - From: "James Taylor" <[EMAIL PROTECTED]> To: Sent: Thursday, June 02, 2005 10:22 AM Subject: web service error handling design issue Hey, another design issue on a different note. In our college course we a told to propogate error up to the top layer/controller and deal with them appropriately. What's the best way to deal with errors in the case of web services? Should I catch the exception and return an appropriate fault node/code and deal with this in the client code or catch the error at the service provider top level and return an appropriate explanation? Just looking for ideas and what way is it done in industry. Thanks to anyone that gives my the time to answer, James. -- Between the question and the answer lies free will
web service error handling design issue
Hey, another design issue on a different note. In our college course we a told to propogate error up to the top layer/controller and deal with them appropriately. What's the best way to deal with errors in the case of web services? Should I catch the exception and return an appropriate fault node/code and deal with this in the client code or catch the error at the service provider top level and return an appropriate explanation? Just looking for ideas and what way is it done in industry. Thanks to anyone that gives my the time to answer, James. -- Between the question and the answer lies free will
