I'm new to SOAP and Axis, and I'm trying to write a single server-side SOAP application class with a single method which can be used to invoke arbitrary methods on arbitrary EJBs. I've succeeded in coding the application with reflection, and I can get a request up to the application and have it processed successfully as long as I use registerTypeMapping() on the client side to define any classes I'm shipping up as parameters.
The problem is that I have no idea what classes may be coming down, other than that they are part of the EJB product classspace (which I control - this tool is a passthru to EJB classes that are part of the same product), and I get a NoSerializerFound exception when Axis attempts to serialize the result of the call. Now, I'm not asking how to make this work. I've read a bit of the code, and I'm pretty sure I could do something to the application that is Axis-specific to get this to work, whether it be a brute-force inclusion within the single class/method on the server side to register all possible return classes, or something more elegant like a chained handler which would front-end the application, capture the return, and dynamically register the return classes before Axis tried to serialize them. What I'm asking is why this should be necessary. If you combine the parameter input to the client-side registerTypeMapping() and the deploy.wsdd and factor out stuff they pass to each other, for classes that use the BeanSerializer all you are really telling Axis is "here's my class, assume it's bean-compliant, and produce an internal mapping for it". Why would there not be a way to specify that this be done automatically if a class were not already in the registry ? In other words, if you're asked to serialize or deserialize a class you don't know about, just turn the Bean(De)Serializer loose on it and see if it works. As I said, I'm new to this stuff, so the answer might be: (a) This is a stupid question, there is no way (b) This is a stupid question, there is a way and you just didn't see it (c) This capability is directly demonized by 43 specification documents you didn't read and reams of flames attached to them (d) We've discussed this before and you just didn't find the right stuff when searching the archives If (a) this isn't against spec (b) I'm not full of sh** (well, on this issue anyway) (c) this isn't some old issue that was consigned to the dustbin months ago (d) there aren't some flagrant issues here with Axis intention or style (e) none of the previous paragraph's (a)-(d) apply then I'd like to think about writing a patch which would do this. However, I obviously do not want to commit the time to reading your code and designing the patch if upon submission I'm going to trip over any of (a)-(e). Looking for some advice... TIA, Frank Griffin
