Jari Kujansuu wrote:
I made Jira issue concerning this problem
http://jira.codehaus.org/browse/XFIRE-1101 but I decided to ask
here too if someone would know workaround to avoid this problem.
I have used XFire 1.2.6 and Aegis & inheritance
(http://xfire.codehaus.org/Aegis+Inheritance) in my SOAP service.
I noticed that usage of inheritance has made my SOAP service unsafe
because SOAP client can easily
crash whole application server running my SOAP service using
non-existing type in xsi:type attribute in SOAP request.
I investigated my problem further.
I executed all JUnit tests for my SOAP interface in debugger and
added breakpoint to ObjectType.readObject method causing problem.
I noticed that ObjectType was never used for reading object from
SOAP request in my existing JUnit tests. ObjectType was used only
in case that SOAP request included type that is not defined in
WSDL or XMLSchema. And this only case when ObjectType is used is
the case I want to avoid.
Next I replaced DefaultTypeMappingRegistry with my own TypeMappingRegistry
implementation that inherits from DefaultTypeMappingRegistry and replaces
ObjectType with my own CustomObjectType implementation like this:
register(tm, Object.class, XSD_ANY, new CustomObjectType());
Then I did really dummy implementation of CustomObjectType that looks like this:
public class CustomObjectType extends ObjectType
{
public Object readObject(MessageReader reader, MessageContext context)
throws XFireFault
{
throw XFireFault.createFault(new IllegalArgumentException("Unsupported
type."));
}
}
Now it seems that this CustomObjectType implementation solves my problem and
at least it did not break any of my JUnit tests.
But since I don't really understand internals of XFire and XFire classes are not
very well documented I would really appreciate if someone who knows XFire better
could explain in what situations ObjectType is used for reading objects and if
there is any potential problems that my CustomObjectType implementation might
cause.
--
Jari Kujansuu
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
