Need factory to avoid direct use of the non-SPI class MessageImpl

A factory pattern as part of the SPI is needed for extensions that need to create MessageImpl objects. See discussion from http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg17590.html quoted below

>>> 2. AbstractInvocationHandler and MessageImpl are in the
>>> org.apache.tuscany.invocation interface package. The first
>>> of these is intended for suclassing, so could be considered
>>> an SPI, but the second is not.
>>
>>
>>
>> I don't think that AbstractInvocationHandler should be an SPI, I
>> suggest to move to it to the core module. I am not sure why
>> Axis2CallbackInvocationHandler extends this class, as I don't really
>> understand the requirement to implement a Java Proxy Invocation
>> Handler in the Axis2 module. I'd suggest to remove it, but I may be
>> missing something...
>>
>> However, MessageImpl is an SPI IMO, as various places in the runtime
>> including extensions should be able to new up a MessageImpl. Do people
>> think that it should be named differently? any proposal?
>>
> For implementation classes that implement SPI interfaces and need to
> be newed up by extension code, a factory approach seems the right
> solution. I'd be happy to make this change. Do we have any existing
> similar factory pattern that I should follow?