I have a fresh installed STS 3.8.2 with one additional plugin subclipse and lombok. I did several fresh installs, but somehow that version has performance troubles. Versions till 3.8.1 worked fine. The most annoying is the JPA Event handler always blocking the Eclipse. I tried to turn off validations already, but it still comes. I am using Windows 10.
Any clue how I can avoid that?
Related
My company has our laptops running Intellij 2018.1 Ultimate Edition.
We have an application that is built on Spring Boot 2.1.1.
When I attempt to run the application, there is no response after hitting the run command. There is no error message, no stack trace, no nothing. All that happens is that the run button gets grayed out and I get no feedback that anything happened.
According to my co-worker, the application works on a different IDE (that I don't have immediate access to).
Any idea what might be happening?
The issue should be resolved by updating to a recent IntelliJ IDEA version.
If it still doesn't help, please contact the support team with the logs attached.
Our application was using spring version 3.2.3.RELEASE and we decided to migrate it to 4.0.9.RELEASE.
After the upgrade we were unable to ever use STS again. When launch the workspace, STS stops responding after some time (5-30 min).
We tried downloading a STS new version, creating new workspaces, disabling all validations. Nothing worked so far but if we use a regular eclipse version we have no problems at all.
Does anyone have an idea on what could be the cause of this issue?
I would suggest to open an issue at https://github.com/spring-projects/spring-ide/issues and provide more details.
Especially interesting will be to capture a thread dump while STS is being unresponsive (using jps and jstack). Would be great if you could attach a few of them to the issue.
You also said that you ran a fresh STS installation (I assume STS 3.9.x) with a fresh workspace. So what exactly did you do before STS becomes unresponsive?
We have our own OSGI plugin with a set of custom code and some java libraries that we use cross projects. It is installed on servers via an update site and imported on developers Domino Designer.
It is working fine up to FP4, but in Domino Designer it is not added to bundles after FP4. For servers and Notes clients it works fine up to FP6 for which we have tested so far.
Tested now with FP7 on my Domino Designer, and the plugin installs fine both via update site and via manual import. However each time I open a database using this library I get build errors. It solves by going to the code, on the error select correct project configuration and adding our plugin to the required bundles. When I close the database and open again, I have to do the same process and we have the same problem with all databases using this plugin.
I have tested starting Notes with the osgi console, but all reports as it is installed normal there.
When viewing in package explorer before fixing the bundle I can see that the plugin is missing from Plugin dependecies and gets added there when doing the fix.
I just installed a fresh Domino Designer for a new user now and upgraded him directly to FP7. He got exactly the same problem. Downgrading him to FP4 solves the problem.
Anyone having the same problem or have ideas to how it can be solved?
I ran into an issue today where my preview server was running an older version of a project instead of the most recently published version. The most recently published version was 1.0.4.10, but after some testing, I determined that version was not the version of the application that the server was retrieving.
After trying a few things, I tried publishing a new version under 1.0.5.0 instead of continuing with the 1.0.4.xx numbering, and that fixed the issue.
VS's auto increment feature recommended 1.0.4.10, but is there an issue with this being the same as 1.0.4.1? So maybe it was running 1.0.4.9? Or something behind the scenes I'm not aware of?
I have an opensource project in GitHub that I am working on with lots of changes, etc. I recently upgrade the maven pom file to use the lastest Spring Release (from 3.1 to 3.2.3). I also upgrade from GWT 2.5 to 2.5.1, and finally from SmartGWT 2.5 to 4.0. After some minor code changes, I was ready to test this.
I can tell you that the Maven code builds successfully, STS/Eclipse report no errors. I can build run the app with no problems. The issue stems from when I run the app, the text boxes cannot have data entered into them, and the link items appear as text boxes.
After doing some research on the SMartGWT forums, I see that the browser cache needs to be cleared which I have done several times. I deleted my entire target directory which also deleted any gwt generated classes, code, ui, nocache.js, etc. I can re-run the maven build which re-creates everything. Again, I can clear my cache, and still the problem happens.
UPDATED:
I created a new SmartGWT 4.0 and GWT 2.5.1 project from scratch. I created a new login screen, I added small bits of code at a time, and watched to see what would happen, would it work or not. It broke when I got to adding all the DynamicForm attributes. Adding the datasource at this time is what broke my login form. I agree there really is no reason to bind this to the datasource at this time. In the onClick of the Submit button, I call the loginDS.fetch(criteria) manually.
So, that would be my advice to anyone working with SmartGWT, if something doesn't work, just start re-adding stuff back slowly, and keep testing until you narrow down exactly what is causing the form/screen to not work. I hope this helps other people!
Check in Eclipse for the project settings, make sure you have the right versions selected for the libraries. For example, the GWT SDK is under Google>Web Toolkit.
I basically just followed my own advice above as well.
I just took the broken widget and re-created a new version, and slowly moved over one method at a ime until I found the broken code. I fixed that piece, and everything worked.
The actual broken code was that I was tying the datasource to my form, and I didn't need to do that in my situation.