> What is the best way to transmit these static constants (associated with a particular class), to the user, if I cannot do it with a BeanSerializer/Deserializer?
Three options come to mind - there's probably more: - The suggestion I made earlier in the thread to add another method/operation to your service that returns a list (array) of strings with valid values for your service method's argument (more overhead because you now have another round-trip to get that info) - Return the valid argument names in a response SOAP header (more work) - Use XSD enumerations to specify the valid values for your service's RPC method argument (haven't played with them much myself, but they should be useful in such a scenario), in which case you'd probably have to use a WSDL file stored on the server, rather than dynamically generated WSDL? -----Original Message----- From: Liviu Chiriac [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 06, 2003 5:31 PM To: 'Mike Burati'; [EMAIL PROTECTED] Subject: RE: how to serialize/deserialize static final fields I understand, by design is not possible. Or at least it is not possible with a BeanSerializer/Deserializer. But what I want to do is not contradictory: I want a user to pick a value out of 3 that I have pre-defined (as constants in my class). I need a way to communicate to the client what those pre-defined values are. When the client sends an object to the server, I check to see which value he picked (out of these 3) and perform different tasks accordingly. (But I need him to pick only one of these 3...) What is the best way to transmit these static constants (associated with a particular class), to the user, if I cannot do it with a BeanSerializer/Deserializer? Liviu -----Original Message----- From: Mike Burati [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 06, 2003 4:53 PM To: 'Liviu Chiriac'; [EMAIL PROTECTED] Subject: RE: how to serialize/deserialize static final fields - The BeanSerializer/Deserializer is designed to work with Bean getter/setter methods, not static constants - You seem to want a class on the client that has final constants, but also want those values transported across the wire from your server instantiation of the ComplexObject class to the client and then set based on the response message's return value? Those two requirements are contradictory.