HI Dennis, Nice to see you back in the mailing list :) Please see my comments inline.
I've been busy, and now traveling, but there were a couple of email exchanges over last weekend that gave details of what I'm trying to implement (see http://marc.theaimsgroup.com/?l=axis-dev&m=115119882403942&w=2 and http://marc.theaimsgroup.com/?l=axis-dev&m=115119916919031&w=2). I'll be getting back to the JiBX unwrapped handling this weekend, as described in these emails.
Yep I've seen the mails and I also think that it is a good solution
I understand your issue with the type mapping table (or at least think I do - I'm going through this quickly), but wonder if you've worked through the implications of handling rpc/lit this way. You're going to want to determine the operation in the generated message binding code based on the type of the value found in the document, then convert the actual values to the parameter passed in to that operation. I'm not sure you really want to be using the type mapping for this purpose, which is supposed to go from element names to Java types. But perhaps I'm misunderstanding.
Lemme explain the problem in detail. Our emitters are designed in such a way to pick the parameters from a type mapper. Type mapper is basically a wrapped hash map with key-value pairs, keys being the QNames and values being the class name. There was no problem till now since there was only one parameter and we used the message reference QName there as the key. If I am to keep the emitters virtually unchanged, I've to populate the type map in such a way that the message parts get a unique Qname that can be used as the key of the type map. -- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
