Here is the workaround I found. You want to expose the interface I into 2 distincts services (ex: same interface but configure differently one with db the other with filesystem) via bean B1 and bean B2 instances of class B (class B implements I).
Spring exporter (or xfire, I do not know the one to blame ;) ) does not let you to do the simple thing, which is what I tried in the first time (see first post of this thread). In order to "make it work", here is the trick : create interface I1 which extends I and interface I2 which also extends I (do not add any method in it). create class B1 which extends B and implements I1 create class B2 which extends B and implements I2 proceed normally to declare your 2 beans as 2 different services. The only requirement for it to work is that B is not a 'final' class. Apparently, xfire (or spring exporter) is doing a binding by interface name so that you can declare the same interface 2 times (bug or not ?). BTW, I finally have differences between the 2 servies so it is good to have I1 and I2 ;) thanks to all the people who provide me some help, regards, chris christophe blin wrote: > > Can anyone tell if this is a bug or not so I can fill a JIRA issue ? > > regards, > > chris > > christophe blin wrote: >> >> Hi, >> >> first, thanks for the answer, I did not know this technique (i.e 1 wsdl >> for many services). >> I did not try it because : >> - my 2 services have exactly the same methods (they implement the same >> interface, only the implementations change). >> - I want to be able to select the implementation from the url of the >> service : if I use localhost/Service1 in my request, I want to use the >> implementation given by Service1. >> >> so if I use the federated services, I will not be able to choose Service1 >> or Service2 from the URL. >> >> So I do not want 1 wsdl with the methods of the 2 services, I want >> distinct services (again that I can select with URL) that implements the >> same methods but in a differrent way. >> >> Do not hesitate to ask for explanation about my use case or other >> technicals details if needed. >> >> regards, >> >> chris >> >> >> Sergei Emelianov wrote: >>> >>> I had the following configuration >>> >>> >>> <bean id="serviceMgr" class="globalization.WebServiceManager"> >>> <property name="webServices"> >>> <list> >>> <ref bean="client1"/> >>> <ref bean="client2"/> >>> </list> >>> </property> >>> </bean> >>> >>> <!-- XFire clients --> >>> <bean id="client1" class=" >>> org.codehaus.xfire.spring.remoting.XFireClientFactoryBean"> >>> <property name="serviceClass"> >>> <value>x.ws.xfire.FederatedService</value> >>> </property> >>> <property name="wsdlDocumentUrl" value=" >>> http://black:8080/Oculus5/services/FederatedService?wsdl"/> >>> <property name="url" value=" >>> http://black:8080/Oculus5/services/FederatedService"; /> >>> </bean> >>> >>> <bean id="client2" class=" >>> org.codehaus.xfire.spring.remoting.XFireClientFactoryBean"> >>> <property name="serviceClass"> >>> <value>x.ws.xfire.FederatedService</value> >>> </property> >>> <property name="wsdlDocumentUrl" value=" >>> http://localhost:8080/Oculus5/services/FederatedService?wsdl"/> >>> <property name="url" value=" >>> http://localhost:8080/Oculus5/services/FederatedService"; /> >>> </bean> >>> >>> Then I was able to obtain list of all endpoints to external web >>> services, >>> yet It was possible to reffer to each of them by list.get(int i). >>> >>> I am sorry if you ment something else. To me list<webservices> sounds >>> like a >>> better idea. >>> >>> >>> Regards. >>> >>> >>> On 12/29/06, christophe blin <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> Hi, >>>> >>>> in xfire-servlet.xml, if you do : >>>> <bean >>>> class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> >>>> <property name="urlMap"> >>>> <map> >>>> <entry key="/Service1"> >>>> <ref bean="service1XFire" /> >>>> </entry> >>>> <entry key="/Service2"> >>>> <ref bean="service2XFire" /> >>>> </entry> >>>> </map> >>>> </property> >>>> </bean> >>>> >>>> >>>> <bean id="service1XFire" >>>> class="org.codehaus.xfire.spring.remoting.XFireExporter"> >>>> <property name="serviceFactory"> >>>> <ref bean="xfire.serviceFactory" /> >>>> </property> >>>> <property name="xfire"> >>>> <ref bean="xfire" /> >>>> </property> >>>> <property name="serviceBean"> >>>> <ref bean="service1Bean" /> >>>> </property> >>>> <property name="serviceClass"> >>>> <value>com.tennaxia.t3.IService</value> >>>> </property> >>>> </bean> >>>> >>>> <bean id="service2XFire" >>>> class="org.codehaus.xfire.spring.remoting.XFireExporter"> >>>> <property name="serviceFactory"> >>>> <ref bean="xfire.serviceFactory" /> >>>> </property> >>>> <property name="xfire"> >>>> <ref bean="xfire" /> >>>> </property> >>>> <property name="serviceBean"> >>>> <ref bean="service2Bean" /> <!-- *************************** >>>> DIFFERENT >>>> --> >>>> </property> >>>> <property name="serviceClass"> >>>> <value>com.tennaxia.t3.IService</value> <!-- >>>> *************************** SAME --> >>>> </property> >>>> </bean> >>>> >>>> then, even if you call localhost/Service1 you will always use the >>>> service2Bean. >>>> >>>> If you inverse the 2 entries in the UrlMapper, then it is always the >>>> service1Bean that is called (i.e even if you called localhost/Service2) >>>> >>>> Do not know if this is a bug or not as I do not have any time to digg >>>> into >>>> the xfire code. >>>> >>>> My workaround is to decalre 2 separate interfaces taht extends the >>>> IService >>>> interface and then to use these 2 different name in the serviceClass >>>> property >>>> >>>> Best regards, >>>> >>>> chris >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Problem-with-Spring-remote-tf2895026.html#a8088333 >>>> Sent from the XFire - User mailing list archive at Nabble.com. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Problem-with-Spring-remote-tf2895026.html#a11426162 Sent from the XFire - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
