Re: [BEANUTILS] Any way to get more helpful error messages from BeanUtils.copyProperties?

[__matthewHawthorne <mh...@alumni.pitt.edu>]

I agree that it makes sense to create some type of pluggable property
exception handling.  Perhaps a user can set listeners or handlers such
as:

PropertyListener
	eventOccured(PropertyEvent e)

or

PropertyErrorHandler
	handleWarning(PropertyException ex)
	handleError(PropertyException ex)


Another idea I've had while using beanutils is the redundancy of having
to catch IllegalAccessException, InvocationTargetException, and
NoSuchMethodException for a lot of the method calls.  I use a small
utility which delegates the call to beanutils, and if an exception
occurs, wraps it in another exception (something like BeanException or
ReflectionException).

Would adding wrappers for the *Utils be useful, or are there frequent
cases where users perform different actions based on the type of
exception that occurs?  My actions for each type of exception are
usually identical.




On Tue, 2003-08-19 at 13:30, robert burrell donkin wrote:
> at the moment, the answer is: not easily. the problem is that beanutils is 
> rather hamstrung by backwards compatibility. there has been talk of 
> factoring out the exception handling so that it could either be hooked 
> into by a pluggable interface or the behaviour subclassed.
> 
> or maybe there's a case for developing subclass exceptions.
> 
> anyone else have any opinions on this?
> 
> - robert
> 
> On Friday, August 15, 2003, at 07:10 PM, K.C. Baltz wrote:
> 
> > Is there any way to get BeanUtils.copyProperties to let you know which 
> > property failed when you get an "argument type mismatch"?  Right now, I 
> > just get an exception and am left to guess which bean property didn't 
> > match.
> >
> > K.C.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 

Re: HttpClient in an applet

[Paul Libbrecht <pa...@activemath.org>]

luke cassady-dorion wrote:
> is there any reason the HttpClient should not work in an applet? i am
> connecting back to the same server and port (localhost:8080) that the
> applet is hosted on but i get this error.
> 
> java.lang.ExceptionInInitializerError 	
> 	at
> org.apache.commons.httpclient.HttpState.<init>(HttpState.java:161)
> at org.apache.commons.httpclient.HttpClient.<init>(HttpClient.java:143)
> 
> 	at
> org.apache.commons.httpclient.HttpClient.<init>(HttpClient.java:128) 	
> 	at
> com.netraker.ui.editor.EditXMLApplet.getNRDL(EditXMLApplet.java:41)
> at com.netraker.ui.editor.EditXMLApplet.init(EditXMLApplet.java:20)

Luke,

I have a version of http-client that has resolve these troubles, just a 
bunch of try/catch.
I haven't had the time to send a patch for it (the one of 
jakarta-logging is sent)... but if you would like I can send it to you.

Paul

Re: HttpClient in an applet

[Michael Becke <be...@u.washington.edu>]

Hello Luke,

HttpClient accesses a number of system properties.  This is a problem 
when running in an unsigned applet because of the security manager. 
Currently, signing the applet is the only way to get HttpClient working 
in this situation.

Mike

luke cassady-dorion wrote:

> is there any reason the HttpClient should not work in an applet? i am
> connecting back to the same server and port (localhost:8080) that the
> applet is hosted on but i get this error.
> 
> java.lang.ExceptionInInitializerError 	
> 	at
> org.apache.commons.httpclient.HttpState.<init>(HttpState.java:161)
> at org.apache.commons.httpclient.HttpClient.<init>(HttpClient.java:143)
> 
> 	at
> org.apache.commons.httpclient.HttpClient.<init>(HttpClient.java:128) 	
> 	at
> com.netraker.ui.editor.EditXMLApplet.getNRDL(EditXMLApplet.java:41)
> at com.netraker.ui.editor.EditXMLApplet.init(EditXMLApplet.java:20)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 

HttpClient in an applet

[luke cassady-dorion <lu...@netraker.com>]

is there any reason the HttpClient should not work in an applet? i am
connecting back to the same server and port (localhost:8080) that the
applet is hosted on but i get this error.

java.lang.ExceptionInInitializerError 	
	at
org.apache.commons.httpclient.HttpState.<init>(HttpState.java:161)
at org.apache.commons.httpclient.HttpClient.<init>(HttpClient.java:143)

	at
org.apache.commons.httpclient.HttpClient.<init>(HttpClient.java:128) 	
	at
com.netraker.ui.editor.EditXMLApplet.getNRDL(EditXMLApplet.java:41)
at com.netraker.ui.editor.EditXMLApplet.init(EditXMLApplet.java:20)

Re: [BEANUTILS] Any way to get more helpful error messages from BeanUtils.copyProperties?

[robert burrell donkin <ro...@blueyonder.co.uk>]

On Wednesday, August 20, 2003, at 02:32 AM, __matthewHawthorne wrote:

<snip>

> Another idea I've had while using beanutils is the redundancy of having
> to catch IllegalAccessException, InvocationTargetException, and
> NoSuchMethodException for a lot of the method calls.  I use a small
> utility which delegates the call to beanutils, and if an exception
> occurs, wraps it in another exception (something like BeanException or
> ReflectionException).
>
> Would adding wrappers for the *Utils be useful, or are there frequent
> cases where users perform different actions based on the type of
> exception that occurs?  My actions for each type of exception are
> usually identical.

the major issue is backwards compatibility. there's a lot of code that 
(potentially) relies on beanutils preserving the current exception 
handling behaviour. the backwards compatibility issue only applies to the 
static utilities rather than the (unreleased) beans. it might be possible 
(but difficult) to alter the exception handling behaviour in the beans 
provided that it was possible to recreate the original behaviour when the 
bean is used through the static methods.

- robert