Hi Dennis, Thanks for the quick response. Please see my comments in-line. BTW I missed the long thread of mails during the weekend so sorry for being late
I don't see it as that complex. Basically there's just a flag for each operation set by the data binding extension, and if the flag is set the message receiver template skips generating the code to call the service method and instead calls the wrapper method (which is then generated by the data binding extension). This is essentially very similar to what is done currently with the toOM and fromOM method generation, but just letting the data binding handle the entire service method invocation. >
OK. I see the point. (and your argument about deser/ser-ialization context seems very much valid too) So this wrapper(unwrapper) method is generated inside the MessageReceiver / Stub ? if the user would not see any specific difference in the artifacts then that would be fine. But still we can generate a piece of common code so that the calling of the toOM is generalized and there is only the absolutely necessary code inside the databinding template.
>
I've said before how for the JiBX handling I really want to control the unwrapping in the data binding extension code, rather than use a generic approach. As long as it's still possible for me to do that and overwrite what's been done by the schemaUnwrappingExtension there shouldn't be any problem with me implementing my changes.
The issue here is figuring out the skeleton/stub method signature. Even if the databinding handles the unwrapping of parameters we have to generate the method sognatures right! To do this we need to know the mapping at the time of generating code. What I suggest is to have an extension that walks the schema and extracts these details and then attach this to the Axis tree for later use (the use would be from the the emitter). For primitive cases the relevant codegen extension can populate the type map relevantly and that should cover the complete mapping.
One of the points of unwrapping is supposed to be to reduce the number of class generated. Besides, in many cases those unwrapped parts are going to be primitives. How do you plan to handle these?
I'm not sure I understand what you're saying here. The method-based approach that I outlined was intended to allow a single OMElement to be passed off and another returned, with all the details of translating that element and calling the service code handled by the data binding code generation. It sounds like you're talking about doing the same thing inline. That's the approach I started with, before deciding XSLT code generation would be much simpler if there's a separate method to handle this for each operation.
We are more or less talking about the same thing :) Only thing is we need to find a solution that would cater for all.
- Dennis --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ajith Ranabahu --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
