I'm sorry. I'm not at all familiar with what you are referencing. Does this Jira issue contain some sort of batch you suggest I try?
Thanks Skip Benson Margulies-2 wrote: > > My experience fits with the Jira that contains the patch for failing to > cascade from one type mapper to the next. For some types, only @XmlType > works. For others, only the .aegis.xml file works. > > -----Original Message----- > From: SkipWalker [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 10, 2007 11:01 AM > To: [email protected] > Subject: Re: [xfire-user] Upgrade from 1.1.2 to 1.2.3: problem > publishing existing services, services wsdls don't implement specified > interfaces > > > I'm pretty sure we are using what I thought was the default, aegis. We > don't > have any configuration for the bindings anywhere. Turning up debugging > I > see lots of XFire debugging > > XMLTypeCreator.getDocument(91) | Mapping file : .... > [classname].aegis.xml > not found. > > There's nothing complicated in our types, and the defaults in 1.1.2 > seemed > to work fine, so I didn't think I would need to do anything as far as > the > bindings go when upgrading to 1.2.3. > > SKip > > > Brice Ruth wrote: >> >> Are you using JAXB2? >> >> On 1/9/07, SkipWalker <[EMAIL PROTECTED]> wrote: >>> >>> >>> I'm trying to upgrade from 1.1.2 to 1.2.3. I'm a novice to XFire as > I >>> didn't >>> originally configure the services using 1.1.2. >>> >>> Running my server, I'm having some baffling issues publishing my >>> services. >>> Looking at the generated wsdls, all of my existing services are > getting >>> messed up when published. Operations are missing from the wsdls and >>> complex >>> types are not being properly included. >>> >>> I've switched all the dependencies to the 1.2.3 requirements. I > didn't >>> see >>> much else as far as instructions for upgrading, so I'm not sure >>> >>> Here's one example simple service example >>> >>> I have a user service with one method that returns a complex type. >>> >>> public interface UserService { >>> >>> /** >>> * Returns a User object for a userId >>> */ >>> public RemoteFileSystemUser getUser(long userId); >>> } >>> >>> public interface RemoteFileSystemUser { >>> //private static Logger logger = >>> Logger.getLogger(RemoteFileSystemUser.class); >>> >>> public Long getId(); >>> public void setId(Long id); >>> >>> public String getUsername(); >>> public void setUsername(String username); >>> >>> public String getFirstName(); >>> public void setFirstName(String firstName); >>> >>> public String getLastName(); >>> public void setLastName(String lastName); >>> } >>> >>> >>> I don't have any aegis mapping files or anything. >>> >>> >>> >>> Publishing the service the with 1.1.2 gives the following for the >>> wsdl:types >>> section >>> >>> <wsdl:types> >>> <xsd:schema >>> targetNamespace="http://service.server.voyant.gossamer.com >>> " >>> elementFormDefault="qualified" attributeFormDefault="qualified"> >>> <xsd:element name="getUser"> >>> <xsd:complexType> >>> <xsd:sequence> >>> <xsd:element name="in0" type="xsd:long" minOccurs="1" >>> maxOccurs="1" /> >>> </xsd:sequence> >>> </xsd:complexType> >>> >>> </xsd:element> >>> <xsd:complexType name="RemoteFileSystemUser"> >>> <xsd:sequence> >>> <xsd:element name="firstName" type="xsd:string" > minOccurs="0" >>> nillable="true" /> >>> <xsd:element name="id" type="xsd:long" minOccurs="0" >>> nillable="true" /> >>> <xsd:element name="lastName" type="xsd:string" > minOccurs="0" >>> nillable="true" /> >>> <xsd:element name="username" type="xsd:string" > minOccurs="0" >>> nillable="true" /> >>> </xsd:sequence> >>> </xsd:complexType> >>> >>> <xsd:element name="getUserResponse"> >>> <xsd:complexType> >>> <xsd:sequence> >>> <xsd:element name="out" type="tns:RemoteFileSystemUser" >>> nillable="true" minOccurs="1" maxOccurs="1" /> >>> </xsd:sequence> >>> </xsd:complexType> >>> </xsd:element> >>> </xsd:schema> >>> </wsdl:types> >>> >>> >>> Publishing with 1.2.3 the types look like this (bad formatting and > all). >>> The RemoteFileSystemUser complex type has lost its properties. >>> >>> <wsdl:types> >>> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >>> attributeFormDefault="qualified" elementFormDefault="qualified" >>> targetNamespace="http://service.server.voyant.gossamer.com";> >>> <xsd:element name="getUser"> >>> <xsd:complexType> >>> <xsd:sequence> >>> <xsd:element maxOccurs="1" minOccurs="1" name="in0" type="xsd:long"/> >>> </xsd:sequence> >>> </xsd:complexType> >>> </xsd:element> >>> <xsd:complexType name="RemoteFileSystemUser"> >>> <xsd:sequence> >>> <xsd:element minOccurs="0" name="id" nillable="true" > type="xsd:long"/> >>> </xsd:sequence> >>> </xsd:complexType> >>> >>> <xsd:element name="getUserResponse"> >>> <xsd:complexType> >>> <xsd:sequence> >>> <xsd:element maxOccurs="1" minOccurs="1" name="out" nillable="true" >>> type="tns:RemoteFileSystemUser"/> >>> </xsd:sequence> >>> </xsd:complexType> >>> </xsd:element> >>> </xsd:schema> >>> </wsdl:types> >>> >>> >>> Other services have similar issues with their complex types, >>> additionally, >>> methods from the interfaces are missing and/or differently named. > For >>> instance, a method called >>> >>> public RemoteFileSystemClient getClient(String clientId); >>> >>> becomes in the wsdl getClientById and the complex type >>> RemoteFileSystemClient loses most of its properties. >>> >>> >>> I'm using the spring ServiceBean to publish the services via the > spring >>> applicationContext. >>> >>> <beans> >>> >>> <import > resource="classpath:org/codehaus/xfire/spring/xfire.xml"/> >>> // .... >>> >>> <bean name="userWebService" >>> class="org.codehaus.xfire.spring.ServiceBean"> >>> <property name="serviceBean" ref="userService"/> >>> <property name="serviceClass" > value="com.mycompany.UserService"/> >>> <property name="inHandlers"> >>> <list> >>> <ref bean="addressingHandler"/> >>> <ref bean="authenticationHandler"/> >>> </list> >>> </property> >>> </bean> >>> >>> <bean id="userService" parent="txProxyTemplate"> >>> <property name="target"> >>> <bean class="com.mycompany.UserServiceImpl" >>> autowire="byName"> >>> </bean> >>> </property> >>> </bean> >>> </beans> >>> >>> Any help on fixing this, or suggestions on how to get the parent >>> interface >>> methods published as part of the service are appreciated. >>> >>> Thanks, >>> Skip Walker >>> >>> -- >>> View this message in context: >>> > http://www.nabble.com/Upgrade-from-1.1.2-to-1.2.3%3A-problem-publishing- > existing-services%2C-services-wsdls-don%27t-implement-specified-interfac > es-tf2950078.html#a8250527 >>> Sent from the XFire - User mailing list archive at Nabble.com. >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >> >> >> -- >> Brice Ruth >> Software Engineer, Madison WI >> >> > > -- > View this message in context: > http://www.nabble.com/Upgrade-from-1.1.2-to-1.2.3%3A-problem-publishing- > existing-services%2C-services-wsdls-don%27t-implement-specified-interfac > es-tf2950078.html#a8260223 > Sent from the XFire - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > > -- View this message in context: http://www.nabble.com/Upgrade-from-1.1.2-to-1.2.3%3A-problem-publishing-existing-services%2C-services-wsdls-don%27t-implement-specified-interfaces-tf2950078.html#a8260846 Sent from the XFire - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
