MyEclipse :: View topic - jar file lock held on lib since upgrading to 6.5M1

MyEclipse: jar file lock held on lib since upgrading to 6.5M1

robvarga - May 18, 2008 - 09:20 PM
Post subject: jar file lock held on lib since upgrading to 6.5M1

Hi,

I noticed the following very disturbing problem since I upgraded from 6.0.1 to 6.5M1. Eclipse version is 3.3.2.

Earlier (up to 6.0.1) I was able to rebuild (with ant) and refresh a jar file which was part of a project (it was in the web/WEB-INF/lib of a MyEclipse Web Project with Spring and Hibernate capabilities enabled, where web is the web root folder).

However, since I upgraded to 6.5M1, ant is unable to recreate that jar file because Eclipse holds a lock on the file, and every time I want to rebuild that jar, I have to exit Eclipse (possibly it would be enough to close the project). I do NOT have the application server running.

Best regards,

Robert

support-nipun - May 20, 2008 - 06:31 PM
Post subject: RE: jar file lock held on lib since upgrading to 6.5M1

I'll get this checked right away. Thank you for bringing this up.

Support-Brian - May 20, 2008 - 08:47 PM
Post subject:

Robert,

I failed to replicate this problem while testing internally.

1) Is any class in the JAR file in question referenced from a Spring bean?
2) Go to Window > Preferences > Spring > Project Builders and turn the AOP builder off. Restart eclipse, does this fix the problem? Please also try turning all the Validators on the Project Validators tab off too.
3) Is it possible for you to create a duplicate of the project without Spring capabilities or Hibernate capabilities and see if adding any of them causes this issue to manifest itself?
4) As you mentioned, does closing the project and reopening it help?

Your answers should help us track this issue down, sorry for the inconvenience caused.

robvarga - May 20, 2008 - 10:20 PM
Post subject:

Hi Brian,

1. Yes, both classes for some beans and also bean definition files declared in the .springBeans file are contained in this jar file. Note however, that this same project (I did not change the .springBeans file nor the bean definition files) was used with ME 6.0.1, and the problem did not occur with that version.

2. Turning off the AOP builder and all the Spring validators and restarting Eclipse did not fix the problem.

4. Closing the project in which the jar file is without restarting Eclipse did not fix the problem. After restarting Eclipse (while the project was still closed) ant was finally able to delete the old version of the jar file. When opening the project again, it was still able to delete the jar file at the first run of ant. However after the resulting workspace rebuild, and attempting to run the ant script again, it started to fail again with being unable to delete that jar file. (And actually once when trying to cancel the workspace rebuild once while the ant script was also scheduled (and waiting practically for the workspace build to complete), Eclipse died altogether). The AOP builder and the Spring validators were still turned off all during this.

As for replication of the problem:

I have two projects.

One is a library project (with Spring and Hibernate capabilities, but it does not matter). I build a jar file from this project via Ant run from Eclipse as a separate 1.4.2 JRE launched in the background. The ant script also attempts to certain delete jar files from the web/WEB-INF/lib folder of the other project with the filename matching a pattern. This is the step which fails with 6.5M1. The newly built jar file would then be copied to the web/WEB-INF/lib folder of the second project, and the second project is then refreshed and rebuilt by the External tools settings.

The second project is a MyEclipse Web project with the jar file built by the ant script in the web/WEB-INF/lib folder. The sourcepath of that library entry is set to the source jar file which is also copied by the ant script to within the second project, but it does not matter at the moment, because that file is never touched because the deletion of the library fails earlier.

Best regards,

Robert

Support-Brian - May 20, 2008 - 10:51 PM
Post subject:

Quote:

1. Yes, both classes for some beans and also bean definition files declared in the .springBeans file are contained in this jar file. Note however, that this same project (I did not change the .springBeans file nor the bean definition files) was used with ME 6.0.1, and the problem did not occur with that version.

Clear. I ask because the Spring tooling has changed significantly since 6.0.1, we now integrate Spring IDE 2.0.4 and I'm wondering if any of the new Spring features are causing this.

I'd like to clarify your replication scenario:
ProjectA: Library project with Spring + Hibernate
ProjectB: MyEclipse Web project

Ant process attempts to delete files from ProjectB/web/WEB-INF/lib and fails.
If the above did not fail, the Ant process would compile a JAR from ProjectA and place it in ProjectB/web/WEB-INF/lib along with a source JAR.
No attempt is made to delete any files from ProjectA.

Is this description correct?

Is ProjectB just a MyEclipse Web project or does it have any additional capabilities?

Thanks for helping us track this down.

robvarga - May 20, 2008 - 11:37 PM
Post subject:

Support-Brian wrote:

Quote:

Project B also has Spring + Hibernate capabilities enabled.

Support-Brian wrote:

Ant process attempts to delete files from ProjectB/web/WEB-INF/lib and fails.
If the above did not fail, the Ant process would compile a JAR from ProjectA and place it in ProjectB/web/WEB-INF/lib along with a source JAR.

Practically yes, except the order is it first compiles project A to a jar in ProjectA/dist (not on classpath anywhere), then attempts to delete the jar file(s) from ProjectB/web/WEB-INF/lib, and this fails. If it would not fail, then it would then copy the newly-built jar from ProjectA/dist to ProjectB/web/WEB-INF/lib.

Support-Brian wrote:

No attempt is made to delete any files from ProjectA.

Correct.

Support-Brian wrote:

Is this description correct?

Is ProjectB just a MyEclipse Web project or does it have any additional capabilities?

Thanks for helping us track this down.

As mentioned above, Project B also has Spring and Hibernate capabilities enabled.

Thanks and best regards,

Robert

robvarga - May 27, 2008 - 10:50 AM
Post subject:

Hi Brian,

did you manage to reproduce this with the upper info?

BR,

Robert

Support-Brian - May 27, 2008 - 07:00 PM
Post subject:

Robert,

Sorry for the delayed response, thanks for the clarifications.

I'm afraid we were still unable to reproduce this issue. We are going to take a look again in a bit, but I am not sure what else I could do to cause it to lock the JAR.

Since we're having a hard time, I would like to isolate the problem further if you have some time:

Please make a backup of your project before trying this.
Could you open your .project file and delete the following lines?

Code:

<buildCommand>
<name>com.genuitec.eclipse.springframework.springbuilder</name>
<arguments>
</arguments>
</buildCommand>

and

Code:

<nature>com.genuitec.eclipse.springframework.springnature</nature>

Save the .project file and restart MyEclipse and re-attempt your build process. If it works now, I know for sure that the Spring features are causing the issue. After this you can go back to the backed up version of your project.

Are you using 6.5M1 by itself or do you have any other plugins loaded as well?

Hope to get this figured out with your help, thanks!

Support-Brian - May 31, 2008 - 01:53 PM
Post subject:

Robert,

I was able to replicate a JAR locking situation if the AOP model referenced a class in the JAR file and only when the AOP builder was turned on. When this builder is on, other non referenced JARs on the classpath may be momentarily locked as well.
Can you confirm that the AOP builder is off for your projects? Please go to Window > Preferences > MyEclipse > Spring > Project Builders and turn the AOP Reference Model Builder off. Additionally go, to Project properties > MyEclipse > Spring and ensure that it is using the workspace settings, or in case you customized the settings, go to the Project Builders page and make sure the builder is off.

Once you restart eclipse, the locking problem should not occur, even after cleaning and building your projects several times. You can confirm that the AOP builder is off by observing the Spring AOP Event Trace view, which should remain empty.

If you still experience issues, could you send us scaled down version of Project B which exhibits this issue? I would like to get this fixed before GA, which is due in around a weeks time.

Thanks!

robvarga - May 31, 2008 - 08:23 PM
Post subject:

Support-Brian wrote:

Hi Brian,

yes, I managed to create a minimal test case, in which both the AOP project builder and even the Spring builder is turned off (even turning off all the Spring validators does not fix the problem). Also, I don't have Hibernate capabilities added to the project, so it definitely is in the Spring capabilities somewhere.

Even when the Spring builder launch configuration is commented out of the .project files (and the AOP builder and all the Spring validators are all turned off), the error still persists. Commenting out the Spring nature and restarting allows the jar file to be deleted (multiple times after one another), but without a restart the bug still persists. Afterwards enabling the Spring nature brings forth the bug again.

I have a guess on where the bug lies: I have a bean config files configured for the project B which would be loaded from the ProjectB/web/WEB-INF/lib/projectA-....jar and also bean file sets defined with those files. Note however that the same thing worked in 6.0.1.

Practically you don't even need the ProjectA, only project B, as the held lock can be observed simply with a file delete attempt.

How can I attach the zipped up version of the project?

Thanks and best regards,

Robert

Support-Brian - May 31, 2008 - 09:30 PM
Post subject:

Robert,

Quote:

Practically you don't even need the ProjectA, only project B, as the held lock can be observed simply with a file delete attempt.

Agree, that is exactly the case we're testing with internally.

If you could mail your test project to support@myeclipseide.com ATTN Brian that would help a great deal.

Thanks for the prompt response!

robvarga - May 31, 2008 - 09:47 PM
Post subject:

Hi Brian,

I sent the project in an email.

Thanks and best regards,

Robert

Support-Brian - Jun 01, 2008 - 11:45 PM
Post subject:

Robert,

Thanks for the sample project, I was able to reproduce the problem immediately and it was not AOP / Validation related as you pointed out earlier.

I noticed you used an import element which was referencing a beans config file in the JAR. If you go to Project Properties > MyEclipse > Spring > Beans, on the Config Files tab, turn "enable support for <import/> element" on. Restart eclipse to make any lock which may already exist on the JAR is released. You should now have no problems replacing / deleting the JAR in question, even after several builds.

You may also want to remove the the config set you have since enabling <import/> support should take care of your cross config bean references.

I also noticed that the <buildCommand> section in your .project file corresponding to the Spring builder was quite odd (perhaps an export problem). You should replace that with the <buildCommand> section mentioned earlier in this thread.

Hope this helps, please let us know how it goes.

robvarga - Jun 02, 2008 - 02:26 PM
Post subject:

Hi Brian,

Support-Brian wrote:

This would almost solve the problem (the file lock is indeed lifted now), except for one thing: unfortunately Spring IDE does not support resolving beans from configuration files imported via the <import> tag when the resource is resolved from the classpath.

This means that I now get the following validation errors:

Failed to import bean definitions from URL location [classpath:applicationContext-framework-hibernate.xml]: file not found

Failed to import bean definitions from URL location [classpath:applicationContext-framework.xml]: file not found

Would it be possible to put in an option of reducing the severity of that error (just for the classpath: case, not the other resource types) to warning?

Support-Brian wrote:

I also noticed that the <buildCommand> section in your .project file corresponding to the Spring builder was quite odd (perhaps an export problem). You should replace that with the <buildCommand> section mentioned earlier in this thread.

Hope this helps, please let us know how it goes.

Well, it was not me who put it there, but I was equally surprised to see them there... And this project was only ever edited with different versions of MyEclipse... It wasn't ever touched by the original Spring IDE, or any Eclipse extensions... So that leaves only a single perpetrator for possibly creating that part. :-)

Best regards,

Robert

Support-Brian - Jun 02, 2008 - 08:17 PM
Post subject:

Robert,

I should have noticed that error myself, thanks. Spring IDE does support importing using "classpath:", but not when the resource is in a JAR, if you try that for a resource in your source folder, it should work fine; so one possible solution would be to modify your projectA build script to move the applicationContext.xml file into the source folder directly, but not sure if that is acceptable for your use.

I also noticed that if you use "classpath*:applicationContext.xml" instead of "classpath:applicationContext.xml", the error marker goes away and the JAR is not locked; unfortunately, you still need to use config sets for any config files you import from JARs and the existence of the resource is not validated. Is this an acceptable workaround for now? This is a core fix that may not be possible at this time.

As for the buildCommand section, I cannot think of anything in MyEclipse which would leave your project in such a state - but I will give related code a once over, just to be sure.

Best regards.

robvarga - Jun 02, 2008 - 08:52 PM
Post subject:

Support-Brian wrote:

Robert,

I should have noticed that error myself, thanks. Spring IDE does support importing using "classpath:", but not when the resource is in a JAR

Yes, that is what I meant, I was not specific enough.

Support-Brian wrote:

if you try that for a resource in your source folder, it should work fine; so one possible solution would be to modify your projectA build script to move the applicationContext.xml file into the source folder directly, but not sure if that is acceptable for your use.

Not really. These classpath entries refer to the included jar file built from Project A.

Support-Brian wrote:

I also noticed that if you use "classpath*:applicationContext.xml" instead of "classpath:applicationContext.xml", the error marker goes away and the JAR is not locked; unfortunately, you still need to use config sets for any config files you import from JARs and the existence of the resource is not validated. Is this an acceptable workaround for now? This is a core fix that may not be possible at this time.

It would possibly be acceptable, however I have to check what is the semantical difference between classpath and classpath*.

If I remember well, it means that multiple occurences of the same resource file name included in differerent jars in the classpath are all loaded. That would be acceptable as my naming convention is that the bean config file name is unique in the system, so in effect classpath and classpath* is semantically the same for me.

Support-Brian wrote:

As for the buildCommand section, I cannot think of anything in MyEclipse which would leave your project in such a state - but I will give related code a once over, just to be sure.

The project was originally created with an older version of MyEclipse (in early 2005) and it was used with several upgrades.

Best regards,

Robert

robvarga - Jun 02, 2008 - 11:00 PM
Post subject:

robvarga wrote:

Support-Brian wrote:

Ehh... seems I should try to upgrade Spring in this project... Spring 1.1 does not support classpath*:. :-(

Best regards,

Robert

Support-Brian - Jun 08, 2008 - 05:30 PM
Post subject:

Robert,

We have fixed this issue internally and it should be available in 6.5GA due any time now. You need to keep the import support on and continue using "classpath:applicationContext.xml", the tooling will find the resource in the JAR file, you will be informed if it does not exist. You also do not need to add this file to your config set.

An additional note, if you move applicationContext.xml from the root of the JAR to within the "lockbug" source folder, classpath:lockbug/applicationContext.xml will correctly locate the bean file even in 6.5M1.

Thanks again for taking the time to work with us on this one.

robvarga - Jun 08, 2008 - 10:55 PM
Post subject:

Cool,

thanks for fixing this :-)

Will it also find the bean config file in a jar included from the classpath if the jar is not explicitly mentioned in the .classpath but provided by a classpath container?

BR,

Robert

robvarga - Jun 08, 2008 - 11:00 PM
Post subject:

robvarga wrote:

Support-Brian wrote:

Ehh... seems I should try to upgrade Spring in this project... Spring 1.1 does not support classpath*:. :-(

Best regards,

Robert

Btw, I created subclasses to the Spring XmlWebApplicationContext, DefaultResourceLoader and DefaultBeanDefinitionParser classes to allow classpath*: prefix and fall back to classpath: behaviour in case they encounter it.

This allows turning on classpath*: with Spring 1.1...

BR,

Robert