Jacques-Olivier Goussard wrote:

I'm a bit lost here. If WSIF is wsdl oriented and java based :),
then isn't the mapping always from xml schema to java (and reverse) ?
Sorry for the question, but I only used AXIS, EJB and Java providers
yet.

hi,

i agree that it is confusing what is essentially model i have in mind is that you start with Java objects you put to WSIFMessage then java objects (identified by FQN) needs to be mapped (see WSIFService.mapType) to XML data type (identified by QName) and that is then mapped by WSIF provider to its specific format. when provider is receiving data the process is essentially reversed.

i hope that it makes easier to understand how WSIF mappings works.

thanks,

alek

/jog


-----Original Message-----
From: Aleksander Slominski [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 18, 2003 2:07 PM
To: [EMAIL PROTECTED]
Subject: Re: [wsif] generic type mapping [Re: bug 16485
[BeanDeserializer error when XML element starts with a capital letter]]


Jacques-Olivier Goussard wrote:


That's the whole point of dynamic invocation...You do not
need a stub to invoke the operations. But I guess you have a point here: patching AXIS is probably not enough, WSIF
should have a way to specify serializers, which could probably be used for streaming in the case of AXIS/SOAP and in place
of the <format:typeMapping> for the EJB and java bindings.


hi Jacques-Olivier,

i think that we should keep in mind that WSIF can be used to invoke not only XML oriented services so any generic serializer should be carefully designed to work with EJB, Java and other WSIF providers. also it probably should fit into WSIF model that is WSDL driven so all mappings should be derived from information provided in WSDL file and be either provider specific (the way you propose) or provider independent (that is what i was thinking) or both ways can be supported too.

thanks,

alek







-----Original Message-----
From: Glen Daniels [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 18, 2003 1:16 PM
To: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Subject: RE: [wsif] generic type mapping [Re: bug 16485
[BeanDeserializer error when XML element starts with a capital letter]]



Hola ant, everyone:

I'm a little confused here. Could you please give me a usage scenario for what you're talking about? Why are people trying to tie apparently unrelated JavaBeans to XML serializations? It seems like either the schema will be built from the Java class to begin with, or the Java class will be built from the schema to begin with... any other pattern a) seems odd, and b) requires some kind of metadata to map the XML to the Java (otherwise, what do you do when the bean has field "name" and the XML has field "moniker"? Case-changing won't help you there...). How do these classes get created?

Trying to grok the situation,
--Glen



-----Original Message-----
From: Anthony Elder [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 18, 2003 12:20 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [wsif] generic type mapping [Re: bug 16485
[BeanDeserializer error when XML element starts with a capital letter]]




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







--
"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




--
"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


Reply via email to