Tom, > The XML string which I receive is generated by a mainframe > application which > does a conversion between an old proprietary data format and XML. > > In your code you mention that it is not necessary to register > Axis classes > explicitly in Axis 1.2 - that Axis 1.2 can do this > dynamically. In that case > I probably need to use Axis 1.2 as this is functionality that I would > require. I cannot use a hardcoded list of data classes (as > done in the > sample code provided) as I have no control over the contents > of the WSDL > file (which is defined by an external partner) so its > possible that the > required datatypes can (and do) change regularly. Of course > it would be > possible to use a hardcoded array of the type classes if we > were to use the > WSDL file along with an XSL file to generate our > serializsation/deserialization source code but I would prefer > not to have to > do this. If Axis 1.2 can handle the datatype registration > dynamically then > this would be preferable. Do you know how this dynamic > registration is > provided in Axis 1.2? Axis does not seem to provide any release notes > detailing functionality changes from one release to the next?
Hm, using Axis 1.2 does not exactly give you *dynamic* registration. What you get there is a readily initialised TypeMapping, so you don't need to manually register the classes. Even in the code version that you have, it would be possible to add a fully dynamic registration capability. We thought about this, but decided against implementing it because we expected it to get a bit complicated, and 1.2 anyway would solve the problem. A scetch of the algorithm is (forgive the fuzzy description): - Do *not* preinitialise the TypeMapping. - Instead handle 'SerializerNotFoundException' (or similar - I cannot remember the actual exception type). If one of these is thrown, get the message from the exception and compute from this the name of the missing type. - Using this name, do a Class.forName() and dynamically register the resulting class in your TypeMapping. - Retry. The next SerializerNotFoundEx should hopefully refer to a different type, handle that like above. But even in this very dynamic case the assumption is that the stub types have been generated and can be loaded. Maybe I do not fully understand what you're trying to do. If you actually want to work without any generated stubs, then you would have to use the dynamic WebService aspects: like putting together a Call object and manually decoding the java.lang.Object returned from the invoke() operation -- we used this in simple cases, but I do not know what happens if the service returnes some complicated datatypes. Maybe here are other possibilities. > Michael thanks very much for the sample code as it is exactly > what I was looking for :) You're welcome. We needed a lot of research to put that code together, may it help many projects... ;^) Best wishes, Michael. -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++
