Hi Dennis, I've been thinking about unwrapping support and here is what my strategy
The basic steps are as follows 1. Using a codegen extension, generate an unwrapped schema by looking at the existing schema. At the time of building this schema we can determine some type mappings but the complex types still need to be processed through a databinding framework to generate the necessary classes. Hence the schema we build here will be only a partial schema which is needed for the inner complex types only. Note that for this process it does not really matter whether the schema was an artificial one ! 2. Once this secondary schema passes along the databinding frameworks the necessary code will be generated. At the end of the codegen run the correct "unwrapped" type mappings will be fully populated. 3. Our codegenerator templates are perfectly capable of handling multiple parameters in method signatures. However the complication comes when one needs to construct the outgoing (in the client side) or explode the incoming (in the server side) message using the unwrapped parameters. This was not a problem at all in the earlier case since there was always *one* parameter. Since all these items that need wrapping are data binding framework dependent, my suggestion is to generate a set of new _toOM_ methods that knows how to concatenate and generate the proper "wrapped" xml. The next question is how should this information be kept in the Axis* hierarchy. When we go for WSDL 2.0 we won't have this problem since WSDL 2.0 by nature does not allow for multipart messages (actually there is no message concept at all) so changing the Axis* hierarchy to cater for WSDL 1.1 may not be the most futuristic design. My guess is extra information needed for WSDL 1.1 is better attached as properties. Our emitters can search for the specific properties and do the needful. Also the 3rd step can be slightly improved with the expense of a few more classes. We can generate the Original wrapped class by looking at the un modified schema and use that wrapper to generate the XML. Since the classes to represent the fields are already generated we can utilize them to populate the wrapped object. Still this needs to be databinding specific! Thoughts ? Ajith On 6/12/06, Dennis Sosnoski <[EMAIL PROTECTED]> wrote:
Sounds good to me. I've spent a few days working on unwrapping support for JiBX, but found the XSLT code generation approach made it very painful. I'll try to get it wrapped up (ha, ha) this week. What time frame are you thinking of for the release? I'd prefer to see a couple of weeks of testing of at least one beta before the actual release, so my hope would be to get all new features in by the end of June and then only do bug fixes until a 1.1 release in mid-July. - Dennis Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117 Davanum Srinivas wrote: > Team, > > There have been some queries on the user list on our next steps...What > do you all think about what should get into the next rev and when we > could possibly cut it? > > My 2 cents, I'd like to see two hot button issues addressed: > #1: unwrapping support in codegen > #2: make ADB databinding use OMDataSource, so that there is an option > to write directly to stream (right now we always pull events). > > Your thoughts please. > > thanks, > dims > --------------------------------------------------------------------- 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]
