Thanks Adam, Sorry for my previous message. Pressed "Send" too early.
I solved my problem for now by putting the services.xml in the /classes folder and modifying web.xml accordingly. I didn't get your last note regarding the XBean style descriptor. The Spring Remoting wiki page doesn't say anything about that. Anyways, thanks a lot for your help, and I appreciate the good work done by the XFire guys, You Rock! :) Rahul -----Original Message----- From: Adam Kramer [mailto:[EMAIL PROTECTED] Sent: Monday, April 10, 2006 5:12 PM To: [email protected] Subject: Re: [xfire-user] easier deployment of services.xml Rahul Pilani wrote: > Thanks Adam, > I tried that. It seems that there is something seriously broken with the > way XFire loads the services.xml file. If the path you specified doesn't > exist under /WEB-INF/classes then it refuses to find the file. > For e.g. if you specified /WEB-INF/services.xml in the context param > value, then the file will have to be at > /WEB-INF/classes/WEB-INF/services.xml > > It's needs to be under /classes because its looking in the classpath for the services.xml file. > For all other software (struts, spring etc.) the above is not a problem. > It's a problem only with Xfire. Any insights? > If you are using Spring, you can use the Spring Remoting features (http://xfire.codehaus.org/Spring+Remoting) to use the Spring DispatcherServlet in place of XFireConfigurableServlet (or any other xfire servlet for that matter). By using this servlet you can place your services configuration file under /WEB-INF rather than in /WEB-INF/classes Note you will not be able to use the XBean service style descriptor with this approach. Check out the wiki page. > Thanks, > Rahu > Best, Adam
