>From the comments Glen added to the bugzilla record the only way to do this
if the bean itself doesn't have the TypeDesc info is to have another class
named as the bean class name appended with "_Helper". (Glen, please leap in
here if there is another way to do this)
As WSIF is designed to be dynamic and we don't know what WSDL will be used
or what bean classes are available before hand, for each operation we'd
have to parse the WSDL schema, find the associated beans, check for setters
for each field, if we don't find one, check again with a name starting with
a lowercase letter, and if that finds one create a TypeDesc class for it.
Perhaps we could do that with BCEL.
Even if there is a way to register the TypeDesc info with AXIS without
generating a class on the fly, this is a lot of work to be doing for each
WSIF operation.
Another option would be for WSIF to have a patched copy the AXIS
BeanSerializer code which has the fix to try with a lowercase 1st letter.
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
Aleksander Slominski <[EMAIL PROTECTED]> on 18/02/2003 16:12:01
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: [wsif] generic type mapping [Re: bug 16485 [BeanDeserializer
error when XML element starts with a capital letter]]
hi,
why do you think that code generation is required?
AFAIK there would be no code generation but just converting in AXIS
provider form WSIFTypeDesc (or something like that) into AXIS TypeDesc?
that would allow other WSIF providers to do do similar things: declare
mappings in provider specific way based on WSIFTypeDesc. we already have
WSIFService.mapType()/WSIFDynamicTypeMap and we may just need to take it
one step further and allow more fins grained mapping control?
thanks,
alek
Owen D Burroughs wrote:
>I don't think that WSIF should be generating code "on the fly". This would
>be very slow.
>
>Owen
>
>
>
>|---------+---------------------------->
>| | Anthony |
>| | Elder/UK/IBM@IBMG|
>| | B |
>| | |
>| | 18/02/2003 12:04 |
>| | Please respond to|
>| | wsif-dev |
>| | |
>|---------+---------------------------->
> >
--------------------------------------------------------------------------------------------------------------------------------------------------|
> |
|
> | To: [EMAIL PROTECTED]
|
> | cc:
|
> | Subject: bug 16485
|
> |
|
> |
|
> >
--------------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>A while ago a user reported a problem with WSIF using the AXIS bean
>serializer when the schema used names which start with a capital letter:
>
>http://marc.theaimsgroup.com/?l=axis-user&m=104203857924370&w=2.
>
>I raised an AXIS bugzilla about it:
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16485
>
>which has now been closed as working as designed. I guess Glen is right in
>what he says about the reasons for closing this, but as the original user
>pointed out, it seems wrong for WSIF to be dependent on the AXIS specific
>TypeDesc info:
>
>
>
>>I would have expected WSIF not to be AXIS dependant for the complex
>>type mapping, as it makes the client code dependant upon the chosen
>>binding. From the code - but I'm really new to WSIF so there may be
>>better ways - it seemed to me that the AXIS provider would have to
>>generate the TypeDesc at runtime (i.e., doing WSDL2Java job) and
>>use it to create the proper BeanDeserializers.
>>
>>
>
>I'm not sure how easy it would be for WSIF to generate the TypeDesc on the
>fly. What does anyone else think about this?
>
> ...ant
>
>Anthony Elder
>[EMAIL PROTECTED]
>Web Services Development
>IBM UK Laboratories, Hursley Park
>(+44) 01962 818320, x248320, MP208.
>
>
>
>
>
>
>
--
"Mr. Pauli, we in the audience are all agreed that your theory is crazy.
What divides us is whether it is crazy enough to be true." Niels H. D. Bohr
