- This topic has 9 replies, 2 voices, and was last updated 6 years, 11 months ago by
.
-
Posts
-
See attached file. I get this NullPointerException frequently. What I’m doing is saving a file, and it’s supposed to copy that file to my Tomcat deployment. Instead I get this vague NullPointerException without a stack trace, and I have to save the file again.
That’d be fine if it occurred once a day. But when I’m messing with stylesheets, I’m saving frequently and Alt-Tabbing to the browser to check my work. I want to be able to rely on MyEclipse to copy the file, and if it did not work, to try again for a bit before giving up with a coherent error message.
Jozef,
I’m hoping there’s there’s more in the Error log (perhaps another error that’s reported at the same time).
1) Can you send us the entire error log?
2) Are you now on CI 8 or CI 9? Is this something new, or has it always been happening?
3) A screenshot of the Tomcat Configuration editor would help.
4) After the error, what do you see in the Servers view against the Tomcat server’s status?Apologies for the frustrating experience.
No need to apologize, I’ll cope with it. I would like to see if I can help to get these issues fixed in upcoming releases though.
1) I think I have found something useful. See attached file. I think it’s the stack trace that leads to the NPE.
2) This is on CI 8. This has been happening for a while now. If I had to guess it would be ever since the new Servers tab was introduced. I hope the attached stacktrace can fix the issue.
3) Alright. “scrn4.png” shows our configuration. I think the culprit may be the publishing interval, which is set to 0 seconds because, and I cannot stress this enough, all we need MyEclipse to do is copy the files from A->B. We have configured everything else in such a way that (My)Eclipse will write its own configuration files to the local workspace. “scrn5.png” shows a change to the launch configuration (accessed via the “Open launch configuration” link on the configuration page) which prevents (My)Eclipse from using its own configuration.
4) The status is stuck on “Publishing…” until I republish (or trigger a republish by saving a file). Then it will publish correctly and the status goes back to “Synchronized”.
Jozef,
Thank you for the log, that helps. Now we did try to reproduce with settings similar to yours (including the 0 second publish interval), but even with “frantic saving”, we couldn’t get it to break.
1) Could you tell me more about the structure of your project? Is it a simple, standalone Web project? Or does it depend on a few other projects in your workspace? I ask because the stack trace references child modules. If yes – what projects are these? A screenshot of your Deployment Assembly property page might help (but is not necessary at this point).
2) When the error occurs, do you think you might be saving multiple files at the same time? Or, could you be saving a file, making a modification and then saving again within a couple of seconds?
1) Attached is the “.settings” folder, “.classpath” and “.project” file of the project.
The project is a Web Project. Note that this is also a Maven Project, as this is forced on us due to another issue.
It would not surprise me if the project being a Maven Project causes it to resolve dependencies on the workspace. We try to turn this off by using the “Disable workspace resolution” option. Unfortunately, due to the opt-out nature of this option this is not always configured correctly. I have confirmed that at least one project in my web deployment was resolving projects from the workspace. This project is completely unrelated to the project I was working on though, so I don’t see how that would cause the NPE.
2) I am saving one file called “style.less”. This file is meant to be copied from “F:\Workspaces\Git\project\WebRoot\css\style.less” -> “C:\development\Tomcat\apache-tomcat-7.0.59\webapps\project\css\style.less”
The compilation of less to css is handled by a servlet which does not modify the source file nor any other files in the “webapps” folder.
It occurs to me that the servlet may still be reading the “style.less” file (which may result in a file lock) while the file is being copied to the Tomcat deployment.
Jozef,
We still couldn’t reproduce with your project set up – though that isn’t too surprising. I will admit that we haven’t yet had a deep tech dive into the code yet, but as you pointed out, the problem may be caused by our inability to write to the file in the destination due to the fact that the servlet is still reading it. If you are able to reproduce this reliably, could we test this theory by turning the converter off for a bit while you edit the file as you normally would? (of course your CSS will remain stale)
Is the log that you see accompanied by an error dialog? Or is it just an error logged? If it’s just the latter, and our assumption that the error was caused by a failure to write the file, an improvement we could make is a better log message – but not sure what else we could do as the lock is out of our hands. What are your thoughts?
I’ll try and see if I can confirm that the error is caused by our resource servlet. I think the best way to do that is to save other types of files (that the resource servlet doesn’t touch) frequently and seeing if the same problem occurs.
The log is accompanied by an error dialog that I have to dismiss every time this occurs.
My thoughts on this is that (My)Eclipse should retry writing the file a couple of times if any exception occurs. Even a single retry may be enough to fix the problem entirely. If there is a slight delay between attempts, say 250ms between the 1st and 2nd attempt, incrementing by a factor of 2 for each attempt up to a maximum of 4? You’d have at most a 7.8 second delay before the final error message is thrown.
Jozef,
Yes, saving other types would work to prove it’s the servlet. Not knowing how the servlet works, I guess it periodically just checks the file, and you’d hit the problem if it was checking when you saved a change? In this case, changing the publish interval to 1 (from 0) wouldn’t help – but if you only see the errors if you make subsequent quick saves (is this the case?) then maybe a delay might help mitigate the problem (by the time we try to push the new change, the servlet has finished reading the previous one).
Clear on the error dialog – that is something we can look at.
On retrying – I did think of that; it will have to be carefully designed of course. This is also not a very common use case – content can certainly be locked, but in our experience, it typically remains locked until something more drastic is done (like shutting down the server).
Jozef,
I’ll try and see if I can confirm that the error is caused by our resource servlet. I think the best way to do that is to save other types of files (that the resource servlet doesn’t touch)
frequently and seeing if the same problem occurs.Did you happen to try this – was the problem only reproducible with files managed by the servlet?
