Alrighty, well does anyone else have any thoughts as to why all my services which worked perfectly fine under 1.1.2 are being published with weird wsdls that 1) don't fully encode the complex types in the service and 2) sometimes renames (e.g. a method public RemoteFileSystemClient getClient(String id) becomes in the wsdl getClientById )
The end result being that the published service doesn't actually implement the interface (from the client point of view) that was supposed to be published on the server. I tried switching to the 1.2.4 with the same results. Considering there are very few notes in the release notes for each subsequent release after 1.1.2 in regards to migration, I don't have a clue what steps I possibly should have taken to prevent my problems. Any suggestions are welcome. Thanks, Skip Benson Margulies-2 wrote: > > The issue is XFIRE-765. However, reading your message more carefully, I > see that you aren't trying to mix two type-creation disciplines, so I > don't think it's going to be relevant. > > -----Original Message----- > From: SkipWalker [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 10, 2007 11:31 AM > To: [email protected] > Subject: [xfire-user] RE: Upgrade from 1.1.2 to 1.2.3: problem > publishing existing services, services wsdls don't implement specified > interfaces > > > 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-interfac > es-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 > > > --------------------------------------------------------------------- > 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#a8302334 Sent from the XFire - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
