mule 2.0/final: CXF and typeMappingRegistry

[ejoch]

Hello,

I'm moving my XFire services (formerly on Mule 2.0 RC3) to Mule 2.0 Final, and experiencing some problems with typeMappingRegistry.

CXF appears to create minOccurs=0, nillable=true for wsdl parameters by default, as XFire did.

Formerly it was possible to get around this as follows:

<custom-connector ....
<spring:property name="typeMappingRegistry" value="custom.FTypeMapRegistry"/>
 </custom-connector>


public class FTypeMapRegistry extends  DefaultTypeMappingRegistry{

        public FTypeMapRegistry(){

                super(null, true);
                Configuration configuration = new Configuration();
                /* here we disuade XFire from its rather annoying tendency to assume that, just because
                // anything in Java can be null, that we want to advertise all that nullity all over.
                 * without this the wsdls have minOccurs=0 on e.g. strings, causes JaxWs to wrap JaxBEelement around
                 * them */
                configuration.setDefaultMinOccurs(1);
                configuration.setDefaultNillable(false);
                super.setConfiguration(configuration);


}

However in CXF 'defaultTypeMappingRegistry' is now final, so that solution won't work. The CxfConnector methods are protected so I cannot see a way to get to the bindings and change the configuration defaults... can anyone suggest a solution?

thanks

[Dan Diephouse-2]

Hi,

Could you file a JIRA for this? I'll get it fixed for the 2.0.1 release.
http://mule.mulesource.org/jira/browse/MULE

Also, I'm going to release the XFire connector for 2.0.0 final in the
next week - so you'll be able to continue using that if you want.

Dan

ejoch wrote:

> Hello,
>
> I'm moving my XFire services (formerly on Mule 2.0 RC3) to Mule 2.0 Final,
> and experiencing some problems with typeMappingRegistry.
>
> CXF appears to create minOccurs=0, nillable=true for wsdl parameters by
> default, as XFire did.
>
> Formerly it was possible to get around this as follows:
>
> <custom-connector ....
> <spring:property name="typeMappingRegistry"
> value="custom.FTypeMapRegistry"/>
>  </custom-connector>
>
>
> public class FTypeMapRegistry extends  DefaultTypeMappingRegistry{
>
> public FTypeMapRegistry(){
>
> super(null, true);
> Configuration configuration = new Configuration();
> /* here we disuade XFire from its rather annoying tendency to assume that,
> just because
> // anything in Java can be null, that we want to advertise all that
> nullity all over.
> * without this the wsdls have minOccurs=0 on e.g. strings, causes JaxWs
> to wrap JaxBEelement around
> * them */
> configuration.setDefaultMinOccurs(1);
> configuration.setDefaultNillable(false);
> super.setConfiguration(configuration);
>
>
> }
>
> However in CXF 'defaultTypeMappingRegistry' is now final, so that solution
> won't work. The CxfConnector methods are protected so I cannot see a way to
> get to the bindings and change the configuration defaults... can anyone
> suggest a solution?
>
> thanks
>
>
>  

--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[ejoch]

Fixed a Jira here:
http://mule.mulesource.org/jira/browse/MFPC-185

The Jira field options were a bit confusing- I wouldn't usually expect a field called 'project name' when submitting a bug! Hope it's gone into the correct place.

CXF documentation's suggested workaround for this hasn't changed since XFire - but that workaround assumes you can get to the bindings, which with the CXFReceiver methods being protected, you can't. So the override of typemappingregistry was a good solution- I *think* this property doesn't exist at all in 2.0.0, possibly because the CXF class formerly being overriden is now final?

perhaps I shall stick with XFire once it's available again.... I can't use the wsdls if they've got mandatory parameters exposed as non-mandatory.

[Andrew Perepelytsya]

MFPC is not the place to file issues. Please create an account in jira first. You'll be able to see all fields then.

Andrew

[ejoch]

I've posted the bug here now:

http://mule.mulesource.org/jira/browse/MULE-3193