You are viewing a plain text version of this content. The canonical link for it is here.

Posted to java-dev@axis.apache.org by bu...@apache.org on 2002/08/14 23:05:39 UTC

DO NOT REPLY [Bug 11707] New: - "Could not convert XXX to bean field YYY" thrown by BeanPropertyTarget.set()

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11707>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11707

"Could not convert XXX to bean field YYY" thrown by BeanPropertyTarget.set()

           Summary: "Could not convert XXX to bean field YYY" thrown by
                    BeanPropertyTarget.set()
           Product: Axis
           Version: current (nightly)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: Basic Architecture
        AssignedTo: axis-dev@xml.apache.org
        ReportedBy: amoore@ciphergen.com


Axis throws the following exception (not exact message - from my notes):

"Could not convert XXX to bean field YYY"

thrown by ... ser.BeanPropertyTarget.set( BeanPropertyTarget:130 )

Environment:

Axis version is a nightly build from 20020807. Server is running under tomcat 
4.0.4 with JDK 1.4 on Linux. Client is stand-alone app running on JDK 1.4 on 
Linux (same box.)

My service returns a fairly large bean with a lot of nested bean properties 
and/or arrays of beans.

My client is a multi-threaded client with one thread per (WSDL2Java generated) 
stub instance. Each thread repeatedly calls the same service method. The 
service blocks all clients until a state change occurs at which time it 
unblocks the clients and they all tend to return from the sevice method at the 
same time.

The problem seems to happen more often when I run with more client 
threads/stubs. They seem to occur after 100 - 200 calls to the service method 
but that is a very rough estimate and there doesn't seem to be a pattern there.

Note - this may be related to defect:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11706