You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Segal, Jeffrey" <Je...@solers.com> on 2007/11/06 00:30:10 UTC

Java first: Binding classes not exposed in service APIs

I asked a smiliar question a few days ago referencing binding subclasses
with Aegis
(http://www.nabble.com/Migrating-XFire-Aegis-inheritance-to-CXF-tf473390
3.html), but I wanted to follow up on the subject and ask a more general
question.  Is binding arbitrary classes (i.e. those that are not
necessarily exposed in a service interface) supported in CXF?  If so,
how is this done using JAXB?  What would the Spring configuration look
like?

Thanks!
Jeff

Re: Java first: Binding classes not exposed in service APIs

Posted by Daniel Kulp <dk...@apache.org>.
On Monday 05 November 2007, Segal, Jeffrey wrote:
> I asked a smiliar question a few days ago referencing binding
> subclasses with Aegis
> (http://www.nabble.com/Migrating-XFire-Aegis-inheritance-to-CXF-tf4733
>90 3.html), but I wanted to follow up on the subject and ask a more
> general question.  Is binding arbitrary classes (i.e. those that are
> not necessarily exposed in a service interface) supported in CXF?  If
> so, how is this done using JAXB?  What would the Spring configuration
> look like?

JAXB has several ways of dealing with subclasses that aren't referenced 
directly from the SEI:

1) If the JAXB classes were generated from it's "xsd -> java" tools (or 
our wsdl2java), there are ObjectFactory object created that would 
reference it.   When the JAXBContext is created, we add the 
ObjectFactory classes for all the packages we know about to the context 
so they could be picked up that way.   

2) The JAXBDataBinding object has a spring configurable 
"extraClasses" property that can be an array of extra classes to add into 
the context so it knows about it.

3) jaxb.index files - for all classes that we know about, we check the 
package for a jaxb.index file which is just a text file with a list of 
other classes in that package to load.   

4) With JAXB 2.1/JAX-WS 2.1, there is support for an XmlSeeAlso 
annotation which you can put on the SEI or other beans to have JAXB add 
those classes.


-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

Re: Java first: Binding classes not exposed in service APIs

Posted by Daniel Kulp <dk...@apache.org>.
Jeff,

Any chance you could log a JIRA and attach a test case for the enum 
problem?   It SOUNDS like Aegis isn't generating the schema for the 
enums correctly.   Or possibly some import namespaces is off or similar.

Dan



On Tuesday 06 November 2007, Segal, Jeffrey wrote:
> Update:
>
> I have verified that this is in fact supported by CXF, just not well
> documented yet.  Here is my Spring configuration, which changes the
> default nillable and minOccurs settings to avoid stubs which wrap
> every Object with JAXBElement:
>
>
>     <bean id="typeMappingRegistryConfiguration"
> class="org.apache.cxf.aegis.type.Configuration">
>         <property name="defaultMinOccurs">
>             <value>1</value>
>         </property>
>         <property name="defaultNillable" value="false"/>
>     </bean>
>
>     <bean id="typeMappingRegistry"
> class="org.apache.cxf.aegis.type.DefaultTypeMappingRegistry">
>         <property name="configuration"
> ref="typeMappingRegistryConfiguration"/>
>     </bean>
>
>     <bean id="aegisBean"
> class="org.apache.cxf.aegis.databinding.AegisDatabinding">
>         <property name="typeMappingRegistry"
> ref="typeMappingRegistry"/> </bean>
>
>     <bean id="jaxws-and-aegis-service-factory"
> class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean">
>         <property name="properties">
>             <map>
>                 <entry key="writeXsiType">
>                     <value type="java.lang.Boolean">true</value>
>                 </entry>
>                 <entry key="overrideTypesList">
>                     <list>
>                         <value>com.foo.bar.A</value>
>                         <value>com.foo.bar.B</value>
>                         <value>com.foo.bar.C</value>
>                     </list>
>                 </entry>
>             </map>
>         </property>
>
>         <property name="dataBinding" ref="aegisBean"/>
>         <property name="serviceConfigurations">
>             <list>
>                 <bean
> class="org.apache.cxf.jaxws.support.JaxWsServiceConfiguration"/>
>                 <bean
> class="org.apache.cxf.aegis.databinding.AegisServiceConfiguration"/>
>                 <bean
> class="org.apache.cxf.service.factory.DefaultServiceConfiguration"/>
>             </list>
>         </property>
>     </bean>
>
>     <jaxws:endpoint
>             id="fooService"
>             implementor="#myFooServiceBean"
>             implementorClass="com.service.foo.impl"
>             address="/foo">
>         <jaxws:serviceFactory>
>             <ref bean="jaxws-and-aegis-service-factory"/>
>         </jaxws:serviceFactory>
>     </jaxws:endpoint>
>
>
> This all works as advertised, which is great.  However, there are two
> features that appear to be lacking.
>
> First, let's say class A (referenced in the overrideTypesList above)
> has an enum property.  CXF will correctly convert it to an XML
> enumeration. However, when creating stubs, the following error occurs:
>
> WSDLToJava Error : Thrown by JAXB : undefined simple or complex type
> 'ns3:SomeEnumType'
>
> Am I right to assume that CXF does not fully support Java 5 enums?
>
> Second, let's say class A has properties of types D, E and F.  If
> class A was referenced in a service API (e.g., com.foo.bar.A getA(int
> id)), CXF is smart enough to bind D, E and F to XML in the resultant
> WSDL. However, if class A is only added to the WSDL via the
> overrideTypesList, classes D, E and F must also be manually added.  If
> D, E and F in turn each have 3 more POJOs of their own, one can see
> how calling out each dependency out gets very unwieldy.
>
> I think these two features would be a great addition to CXF's
> capabilities.  Thoughts?
>
> Cheers,
> Jeff
>
>
>
> -----Original Message-----
> From: Segal, Jeffrey [mailto:Jeffrey.Segal@solers.com]
> Sent: Monday, November 05, 2007 6:30 PM
> To: cxf-user@incubator.apache.org
> Subject: Java first: Binding classes not exposed in service APIs
>
> I asked a smiliar question a few days ago referencing binding
> subclasses with Aegis
> (http://www.nabble.com/Migrating-XFire-Aegis-inheritance-to-CXF-tf4733
>90 3.html), but I wanted to follow up on the subject and ask a more
> general question.  Is binding arbitrary classes (i.e. those that are
> not necessarily exposed in a service interface) supported in CXF?  If
> so, how is this done using JAXB?  What would the Spring configuration
> look like?
>
> Thanks!
> Jeff



-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog

RE: Java first: Binding classes not exposed in service APIs

Posted by "Segal, Jeffrey" <Je...@solers.com>.
Update:

I have verified that this is in fact supported by CXF, just not well
documented yet.  Here is my Spring configuration, which changes the
default nillable and minOccurs settings to avoid stubs which wrap every
Object with JAXBElement:


    <bean id="typeMappingRegistryConfiguration"
class="org.apache.cxf.aegis.type.Configuration">
        <property name="defaultMinOccurs">
            <value>1</value>
        </property>
        <property name="defaultNillable" value="false"/>
    </bean>

    <bean id="typeMappingRegistry"
class="org.apache.cxf.aegis.type.DefaultTypeMappingRegistry">
        <property name="configuration"
ref="typeMappingRegistryConfiguration"/>
    </bean>

    <bean id="aegisBean"
class="org.apache.cxf.aegis.databinding.AegisDatabinding">
        <property name="typeMappingRegistry" ref="typeMappingRegistry"/>
    </bean>

    <bean id="jaxws-and-aegis-service-factory"
class="org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean">
        <property name="properties">
            <map>
                <entry key="writeXsiType">
                    <value type="java.lang.Boolean">true</value>
                </entry>
                <entry key="overrideTypesList">
                    <list>
                        <value>com.foo.bar.A</value>
                        <value>com.foo.bar.B</value>
                        <value>com.foo.bar.C</value>
                    </list>
                </entry>
            </map>
        </property>

        <property name="dataBinding" ref="aegisBean"/>
        <property name="serviceConfigurations">
            <list>
                <bean
class="org.apache.cxf.jaxws.support.JaxWsServiceConfiguration"/>
                <bean
class="org.apache.cxf.aegis.databinding.AegisServiceConfiguration"/>
                <bean
class="org.apache.cxf.service.factory.DefaultServiceConfiguration"/>
            </list>
        </property>
    </bean>

    <jaxws:endpoint
            id="fooService"
            implementor="#myFooServiceBean"
            implementorClass="com.service.foo.impl"
            address="/foo">
        <jaxws:serviceFactory>
            <ref bean="jaxws-and-aegis-service-factory"/>
        </jaxws:serviceFactory>
    </jaxws:endpoint>


This all works as advertised, which is great.  However, there are two
features that appear to be lacking.  

First, let's say class A (referenced in the overrideTypesList above) has
an enum property.  CXF will correctly convert it to an XML enumeration.
However, when creating stubs, the following error occurs:

WSDLToJava Error : Thrown by JAXB : undefined simple or complex type
'ns3:SomeEnumType'

Am I right to assume that CXF does not fully support Java 5 enums?

Second, let's say class A has properties of types D, E and F.  If class
A was referenced in a service API (e.g., com.foo.bar.A getA(int id)),
CXF is smart enough to bind D, E and F to XML in the resultant WSDL.
However, if class A is only added to the WSDL via the overrideTypesList,
classes D, E and F must also be manually added.  If D, E and F in turn
each have 3 more POJOs of their own, one can see how calling out each
dependency out gets very unwieldy.

I think these two features would be a great addition to CXF's
capabilities.  Thoughts?

Cheers,
Jeff



-----Original Message-----
From: Segal, Jeffrey [mailto:Jeffrey.Segal@solers.com] 
Sent: Monday, November 05, 2007 6:30 PM
To: cxf-user@incubator.apache.org
Subject: Java first: Binding classes not exposed in service APIs

I asked a smiliar question a few days ago referencing binding subclasses
with Aegis
(http://www.nabble.com/Migrating-XFire-Aegis-inheritance-to-CXF-tf473390
3.html), but I wanted to follow up on the subject and ask a more general
question.  Is binding arbitrary classes (i.e. those that are not
necessarily exposed in a service interface) supported in CXF?  If so,
how is this done using JAXB?  What would the Spring configuration look
like?

Thanks!
Jeff