[gsl1]

I am using Eclipse 3.3.0 and MyEclipseIDE 6.0M1. I have a number of jars that are used as libraries that have been placed under WEB-INF lib. One of these jars has a class in a package that I have overridden by creating a new class in a java file that has been placed in the project’s src folder. The src folder is a recognized src folder by Eclipse and the class has been constructed such that it is in the same package as the class it is overridding in the jar file. A class file is generated during a build and ends up in the WEB-INF classes folder. The source folder has been placed earlier in the project’s Build Class Path. Everything works just fine. The class I created overrides the class found in the jar file.

When I go to debug and a breakpoint is set on the class I created, the class file is displayed in the Eclipse class file editor when the web page is requested. No source is attached at this point, so I point the class source at the source I created under the project’s src directory.

This works great until I change the source code. Following this a cached version of the source code is used that is out of date with the newly changed source code. Is there a better way to set this up? No matter what I do I can’t seem to tell Eclipse/MyEclipse to use the new source code once I change the source or to automatically use the latest source code. It continues to use the cached version of the source from the first time source was attached.

-=> Gregg <=-

[Loyal Water]

Can try Project > Clean. Does that help ?

[gsl1]

I found part of the problem. I copied the contents of one project to another project. Somehow the link between the generated class and the source in the old project was retained in the new project. I moved the source out of the src file in the old project and then debugged the new project. This forced the class editor to come up and ask for a source file at which point I attached the correct source; however, eventhough I have done this, changes to the new source file are not being accounted for and I can find no way to change the link anymore.

Yes, I have done project clean on multiple occasions, I have stopped the server, undeployed the webapp and removed all traces of the webapp by hand that I could find. Somehow Eclipse or MyEclipse is holding on to this link and there doesn’t seem to be any way within the IDE to delete the link that I can find. Where is this link established and cached?

-=> Gregg <=-

[gsl1]

I did some more with this. It seems that I can consistently cause and workaround this problem. Additional info on my setup follows. I created a MyEclipse project with web capabilities and proceeded to create a working webapp which I deployed to Tomcat 6.0.13 using the MyEclipse AppServer connector. One of the jar’s I’m using has a class that I needed to rewrite to make the webapp function properly. I did not want to disturb the class file in the jar, so I simply grabbed the original source and modified it accordingly by creating an identical package tree under an Eclipse recognized src folder. I then proceeded to guarantee that the src folder was before the jar file in the build path. This worked perfectly and I have used this technique before successfully both in and outside of Eclipse. I deployed the webapp to Tomcat as context “test”. I then placed a breakpoint in the new class and started up Tomcat. The test context was loaded based upon console output and when the breakpoint was reached after attempting to go to the pertinent URI in FireFox, the Eclipse class file editor dutifully brought up the class file displaying assembler and requesting that a source file be attached. I then attached the appropriate source file found under the src directory and package tree. Debugging proceeded normally and I got the webapp to function as I desired. I stopped debugging and Tomcat and undeployed the webapp.

Now I wanted to port this webapp to a new version of serveral of the jars. This new version contains significant changes that require that I alter the class file yet again to make the webapp functional again. Since I have a working webapp, I don’t want to disturb it in any way, so I created a new MyEclipse project with web capabilities with a new name. I copied the contents of the old project excluding the various “.” project files. I changed the deployment context in this new project to test3 (test2 was abandoned but not discarded). In this new project, I made my changes to the webapp to make it compliant with the new version of the jars. I then set a breakpoint in the modified source file, this is a modified copy of the file found in the previous project. I cleaned this project, deployed to and started Tomcat. I again attempted to go to the pertinent URI in FireFox and the debugger stopped at a in the class file editor using the source from the old project.

Ok, now I stopped everything, removed the source file from its package directory in the old project, cleaned both projects, redeployed the new project and started again. As soon as I cleaned the new project, the source file in the class file editor that I had been debugging reverted back to assembler. In other words the link to the old source file disappeared which, of course, is good. Once I started debugging the class file editor brought the pertinent class file forward and agains requested that I attach the proper source. I did as before, but this time attached the source from the new project. This worked correctly and changes to the source were compiled as expected and synch-on-demand worked as I expected.

Now, if I stopped everything, undeployed the new webapp, moved the old source file back into the old project, cleaned both projects and redeployed the old webapp, the old class file remained attached to the new source file. In order to force the old class file to use the old source, I had to, this time, remove the new source file from its package directory, move the old source file back into its package directory, clean both projects and start again.

It seems that I might have found an unhandled corner case. I can repeat this back and forth problem consistently. It seems that once a source file is attached to a class file, no matter what project it is in, at least when that file is overriding a like file in a jar, Eclipse does not distinguish which project the source file comes from and leaves it attached until it can no longer find it.

Can anyone else repeat this behavior?

-=> Gregg <=-

[Riyad Kalla]

Gregg,
First let me thank you for the *very* thorough description… probably the most detailed issue report ever.

Anyway, I would point out that you need to close the old projects you aren’t using during debugging *if* they contain identical package structures and class files… because the way the debugger works is that all open projects are valid targets for a break point during a running debug session. So if you have multiple projects with the same package structure, class files, source files, etc. the debugger will hit the first one it finds (sometimes incorrectly).

I hope this does the trick.

[gsl1]

Yes, closing the project after undeploying the competing project’s context does seem to resolve the issue. However, this seems quite counterintuitive to me. Is there some advantage to purposely structuring Eclipse to work in this way? It seems to me that the better approach would be to treat each project in essentially its own name space so that this type of “hidden” issue does not occur when more than one project is open with competing classes. Is this a limitation of how debugging works in the app server itself? I guess I still look at this as a bug versus a “feature” and I would tend toward reporting it to the Eclipse dev group’s issue tracking system unless you can present some valid reason to justify this functionality.

-=> Gregg <=-

[Riyad Kalla]

Gregg,
The behavior does seem odd for sure.

Consider the situation where 1 EAR contains 10 separate projects, some Web and some EJB, and you set a breakpoint in Web project #3 and EJB project #3… and you run your huge EAR. Myeclipse has to consider all open projects as possible targets for that breakpoint as it runs.

Then you take a look at what the app server hands back to us, maps code lines to source lines, but with no project qualification… it just says something like “com.blah.UserDAO code line 12 is Source line 44” so we break on source line 44 of class “com.blah.userDAO”… that lookup executes in the platform and finds the first occurance of it.

So all you should need to do is close the projects you don’t want to use during a debug session that *do* have identical layouts to avoid that confusing.

[Author]

Posts