Xiaoping, Welcome back from your travels!
I'd like to encourage *you* to integrate those new classes into Axis - it's really not that hard after a bit of practice. I could do it for you, but I think you'll get up to speed quicker if you do it yourself and the result will be much more worthwhile. I still don't have a thorough understanding of all the org.apache.axis.message classes, so what I'm doing is starting near the top of the XML structure of a SOAP message (as describe e.g. in the architecture guide) and then massaging the Axis classes to be one-for-one with the JAXM interfaces and then making each Axis class implement the corresponding JAXM interface (including implementing the JAXM methods, often in terms of the existing Axis methods). I've also made a start on some unit tests for the message subsystem - in package test.message - and I'd recommend that you add unit tests to that package for the classes you add. (Once the obvious matches have been made, we'll need to add those classes that are required by JAXM but not yet present in Axis, and that will take a bit more thought. On the other hand, I guess most of the componentry is there in Axis already and it's mainly a question of searching it out. To that end, the IRC chat is often useful for having interactive discussions with experts like Glen, Russell, etc.). You also need to get to the point where you can issue "ant clean all" and eventually get "BUILD SUCCESSFUL" if you are not there already. Then you can have some certainty that you are not going to break the build. If the build shows your new unit test cases running successfully, then when your changes get integrated, those unit tests will be of permanent benefit as a regression test. Finally, you should submit your changes as new files plus a patch file created using cvs diff -u. Of course, when I or someone else merges in your changes, they should eye-ball the changes and run a full build again before committing the changes, as a safety net. You may get a bit of stylistic feedback initially until you are used to coding in the "house style", but that's usually pretty superficial - avoid long source lines, putting message text in resource.properties rather than embedding it as String literals, using the commons logging API for making log (a.k.a. trace) entries, etc.. I hope you don't feel this is too daunting. Let me know if you have questions as you go along and I'll try to help where I can. If you continue to communicate via axis-dev, I'm sure others will chip in as appropriate. Plus the trail of discussion might be useful for future new developers. Probably the worst that can happen is that some changes will slip through which are in some sense wrong, like some I made yesterday, but it's pretty easy to reverse history using cvs, so you shouldn't let that concern you too much. Glyn BTW, Glen Daniels reads the axis-dev list, so you don't need to copy him on notes separately. I'm not even sure his old email address ([EMAIL PROTECTED]) still works!
