[jasongriebeler]

I’m running into an issue which I believe is related to myEclipse (5.0.0) and not xFire. I am attempting to move the services.xml file from /WEB-INF/classes/META-INF/xFire/services.xml. I was able to specify the location to be elsewhere in my class path upon adding Web Services Capabilities to my project. However, the META-INF xml file is still being generated. Then when I interact with CVS I am getting an error complaining that the file is not local (error pasted below). I have made sure that it is not included anywhere within the project or CVS. But whenever I refresh the project or try and synchronize with our CVS repository the META-INF xml file is regenerated. Is this something myEclipse is doing? Can I configure this to not occurr?

I have also noted that when I specify to generate the services.xml file elsewhere it is not updating the web.xml in accordance with xFire’s specification. I am using the “update your web.xml file” as how to properly configure my application http://xfire.codehaus.org/XML+Configuration

Thanks in advance for your effort.

– jason

CVS ERROR:
Errors have occurred while calculating the synchronization state for CVS Workspace.
Resource /ddeWeb/WebRoot/WEB-INF/classes/META-INF is not local.
Resource /ddeWeb/WebRoot/WEB-INF/classes/META-INF is not local.
Resource /ddeWeb/WebRoot/WEB-INF/classes/META-INF is not local.

[Riyad Kalla]

Jason,
I believe this is a CVS/Team operation issue. After you removed the XML file from it’s old location, did you commit that “removal” and then aftering adding it ot the new location did you then commit that “addition”?

[jasongriebeler]

Hi Riyad,
Thanks for the quick response. The file is not in CVS. I looked in the actual cvs root and it is not there. The only reason I mention CVS at all is because Eclipse by default ignores anything in the classes directory, if I have my information correct. Since this file is located within that directory I am unable to check it in. The file is regenerated even without CVS interaction. All I have to do is “refresh” my project by right clicking on the project and saying refresh and the file shows up again. If there is a work around to committing the classes directory I would like to try it, however I did not see the classes folder included in my CVS ignore setting.

thanks again,

jason

[jasongriebeler]

To provide more information about the CVS interaction. When the commit wizard is started, it always displays the META-INF/xfire directory, but the services.xml file is never actually committed.

[Riyad Kalla]

The only reason I mention CVS at all is because Eclipse by default ignores anything in the classes directory, if I have my information correct.

Actually that’s not the case, you have to explicitly set your classes dir in a .cvsignore file to be ignored, nothing is ignored by default.

The file is regenerated even without CVS interaction.

Then it most likely lives in your /src directory in the respective place, because your output dir (/classes in this case) is deleted and recreated every time your project is rebuild, that is how Eclipse handles output dirs. So if the file keeps popping up in your output dir, it is being “built” from some other location (source directory).

All I have to do is “refresh” my project by right clicking on the project and saying refresh and the file shows up again.

Hmm, that’s a little more strange. If you erase the file, then do a project/clean, does it pop back up? If you do a Find for some text in that file that is unique to it on your entire workspace, do you only get that 1 result of the file in your /classes dir? Sounds like something went screwy…

If there is a work around to committing the classes directory I would like to try it, however I did not see the classes folder included in my CVS ignore setting.

General rule of thumb is to never commit generated resources to source control (like Javadoc, classes, dist JARs, etc.), but each development house is different.

[jasongriebeler]

Riyad,

Then it most likely lives in your /src directory in the respective place, because your output dir (/classes in this case) is deleted and recreated every time your project is rebuild, that is how Eclipse handles output dirs. So if the file keeps popping up in your output dir, it is being “built” from some other location (source directory).

services.xml actually shows up twice in the classes directory. It shows up where I would like to assign it com.myCompany.webservices and in META-INF/xfire.

To simplify our discussion, I have taken CVS out of the issue entirely. I created a new web application through the Web Application wizard, I then add Web Services Capabilities. At this point I change the location of the services.xml file within the web services wizard. The file shows up in the specified location as well as in the META-INF/xfire directory as described before. From my filesystem I remove the classes/META-INF folder. When I refresh my project within eclipse the folder is regenerated.

Here is the contents of my com.genuitec.eclipse.ws.xfire.prefs located in .settings:

 #Wed Sep 27 16:45:00 CDT 2006
eclipse.preferences.version=1
xfire.services.location=src/ws/services.xml
xfire.servlet.name=XFireServlet

Is there any other information I can provide? Thanks again for your continued support.

jason

[Brian Fernandes]

Jason,

I apologize for not getting to this earlier.

1) The file at the location you specify for services.xml during the capability addition / new project creation is the file which you should be editing and working with – this is the primary services.xml file. However, XFire (at least the version we shipped) was refusing to play nice with services.xml files in any location other than META-INF/xfire. So as to not inconvenience users with having to maintain a configuration file at that location, our Web Services builder will always copy your primary services.xml file into that location so that XFire works. If the builder does not creat a copy of this file, XFire won’t be able to locate the file. We are going to investigate whether this issue has been fixed in XFire 1.2 which we will be integrating soon.

2) There was a bug in the builder due to which the META-INF/xfire/services.xml file was not marked derived as it should have been. This caused it to interfere with CVS in the manner you described initially – with the “not local” warnings. The good news is that this bug has been fixed and the fix has been released in MyEclipse 5.0.1 – you need to upgrade to that and you should be fine.

I have also noted that when I specify to generate the services.xml file elsewhere it is not updating the web.xml in accordance with xFire’s specification. I am using the “update your web.xml file” as how to properly configure my application

Could you be a little more specific? What is being generated into web.xml and what did you expect – does your application work?

I hope this clears things up,
Brian.

[jasongriebeler]

Hi Brian,
Thanks for clearing up the weird behavior, I think I might have some information that might help us both out. I think the wizard used by myEclipse is missing an input-param specifying the location of services.xml file. I had to manually add the config to the web.xml file. Please see below. It is documented by codehaus here: http://xfire.codehaus.org/XML+Configuration

<servlet>
<servlet-name>XFireServlet</servlet-name>
<servlet-class>org.codehaus.xfire.transport.http.XFireConfigurableServlet</servlet-class>
<init-param>
<param-name>config</param-name>
<param-value>com/db/dde/webservices/services.xml</param-value>
</init-param>
<load-on-startup>0</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>XFireServlet</servlet-name>
<url-pattern>/services/*</url-pattern>
</servlet-mapping>

I was successfully able to get xfire to pick up the services.xml file in another location using the xfire version distributed with myEclipse 5.0.0.

Do you have any suggestions on correcting the CVS behavior I am seeing? I tried using a standalone version of eclipse (without myEclipse) and the error disappeared.

thanks again,

jason

[Brian Fernandes]

Jason,

Do you have any suggestions on correcting the CVS behavior I am seeing? I tried using a standalone version of eclipse (without myEclipse) and the error disappeared.

Yes, please re-read my last post. Upgrade to MyEclipse 5.0.1 and you won’t have the CVS issue anymore.

I think the wizard used by myEclipse is missing an input-param specifying the location of services.xml file. I had to manually add the config to the web.xml file.

Actually that isn’t entirely true. If you put the services.xml file under META-INF/xfire/, then XFire will pick it up automatically. Now we don’t expect you to put the services.xml file into that location, as I mentioned in my previous post, please work with the services.xml file you specified when you created the project and our builder will copy it to the location expected by XFire. In other words, you do not need the init-param specifying the location – simply becuase our builder will copy your services.xml file, wherever it may be, and put it in the default location that XFire checks

Why don’t we just specify the location in an <init-param> element instead of copying it like we do?
This is because the early version of XFire we started with simply refused to work with a services.xml file in any other location, even if the init-param was correctly specified. We upgraded the XFire libraries we shipped with MyEclipse a couple of times since but didn’t re-check to see if the XFire team fixed this issue. Now that you mentioned it works, we will take a look at is as we integrate XFire 1.2.x for MyEclipse 5.0.3

Hope this helps,
Brian.

[Author]

Posts