I'm just getting into GAE and I'm using STS (derivative of Eclipse). I'm currently getting a project set up to use Spring and Apache Tiles under GAE. I've got it mostly configured properly and it seems to work. My biggest problem is figuring out how others handle day-to-day developing in this kind of environment.
I make tons of changes to the front-end JSPs but so far it seems like I have to stop the GAE server and restart it every time I make a small change to a JSP. Having to restart when I make changes to the controller is fine, but having to restart it for a simple JSP change is driving me crazy.
Is there a way to have the GAE environment reload JSP changes in Eclipse/STS?
I'm using Maven for AppEngine project, so whenever I build the project, there will be a project target directory generated/updated which is where the server will load the files from. When I tried to update my jsp/css/js files, I always open the file in that directory and update it there. Once I'm satisfied with the it, I will copy the changes to my source file.
Essentially, I think for you, you can find out where is your target directory, and try to edit your files from there.
I'm not sure if my workaround is suitable for you but maybe you can get one or two here.
Apart from that, there are people using JRebel which is a hotdeploy tool. There is a AppEngine version of JRebel there, but I suspect it is not free...
I'd suggest to take a look at JRebel. Even if it is commercial software, it will save you a lot of nerves for this kind of development
You need to set parameter:
server.jsp-servlet.init-parameters.development=true
(Put it into application.properties if you use spring boot)
Related
I have observed an inconsistent way properties are being read in Eclipse. I have a very simple Springboot web project with typical property files. Here is my project layout:
Notice the two property files: testapplication.properties and application.properties. They are identical at this point, the intention is to use them for test and non test environments.
When I try to run this application in Eclipse, I am getting an error about missing expected property values, for example:
Could not resolve placeholder 'min.thread.count' in value "${min.thread.count}"
When I run the same setup using gradle's bootRun task, it works fine.
When I run the same setup in InteliJ it works fine.
If I rename the testapplication.properties to application.properties the application runs fine in Eclipse. As such it is using property form test folder.
In addition, I am pretty sure when I started Eclipse this morning I was able to run the application with a proper application.properties and testapplication.properties files. I was working on a unit test and renamed the testapplication.properties to application.properties, did some work, then renamed it back to testapplication.properties the application refused to start. I have attempted to replicate it: shut down eclipse with two different property files (application and testapplication), start it again and run application. However, at this moment I have the same issue (complaining about missing property value).
As you can see this i weird behaviour. As it stands I find that I cannot use Eclipse as I am not sure what it will do. I've switch to community edition of InteliJ as it seems to be working correctly. But as a long time fan of Eclipse I am heartbroken :)
Does anyone have any clue what could be causing this?
EDIT:
I have checkin in my test project here:
https://github.com/twolak2003/CamelSpringBootEureka.git in branch PropertyFileIssue. Simply clone, switch to PropertyFileIssue branch, import to eclipse as gradle project.
It is a simple vanilla spring cloud boot project running a eureka server and eureka client. For the purpose of this issue we'll just concentrate on eureka-service.
I am using latest Eclipse Oxygen. I did notice the same issue in Eclise Neon. I switched to Oxygen hoping the issue will go away. Only plugin is the Spring IDE. Using Java 8 to run this.
Test 1: Start the EurekaService/src/main/hello.java as Java application.
It starts fine and will read the src/main/resources/application.property file.
Test 2: Rename the EurekaService/src/main/test/resources/restapplication.properties to EurekaService/src/main/test/resources/application.properties. Start the EurekaService application again.
Findings: It starts fine as well BUT it uses property file in the /src/test/resources. This to me is issue as well, it should not be using /test/ for running the application.
Test 3: Now rename the /src/test/resources/application.properties to /src/test/resources/testapplication.properties again. (this is repeat of test1). Once again run EurekaService/src/main/hello as java application.
Finding Despite this being a repeat of test1 the test failed due to "Could not resolve placeholder 'tomek.prop' in value "${tomek.prop}"".
Am I doing something really stupid or is there an issue?
For now with heavy heart I am switching to InteliJ to keep my project going. The behaviour of Eclipse is just too unpredictable for me to stomach for now :(
So far I don't have a correct answer for this other than stop using Eclipse :). But there is workaround.
DO NOT use more than one application.property file.
If you need test properties to override actual properties then name your file as anything else but "application.property". Otherwise you'll get unpredictable behaviour and your Eclipse runtime get's confused.
I'm currently working on developing a custom workflow with many custom behaviors and scripts. I'm using the Alfresco Maven SDK to build and test my project as I develop it. This necessitates that I restart the repository-tier tomcat server every time I want to make a change/update my workflow files. I am getting quite frustrated with how long this takes each time, and it means that I'm wasting time while waiting for the server to restart, especially when I've made a small typo in one of my files.
I'm looking for a way (if it's possible) to update my files (in particular the bpmn process file) and apply these changes to my Alfresco instance without having to restart the tomcat servers each time. I've set to true in my service-context.xml, and I have also tried to redeploy the workflow from the admin-workflow-console, but my changes do not take place unless I manually restart the server.
I am using: Alfresco Community 5.2, Maven SDK 2.2
Any tips or suggestions would be very welcome!
Yes, you can do it by
workflow admin console
URL
http://<server>:<port>/alfresco/s/admin/admin-workflowconsole
Ex :: deploy alfresco/workflow/<workflow-definition>.xml
path for your workflow definition file.
Refer this docs for more information
https://community.alfresco.com/docs/DOC-5079-workflow-console
In sbt there is a live mode, if I use sbt ~run, then every time a java source changed, it will reload automatically. playframework also support that so that when change a source code, we don't reload manually. For gradle, I am running spring boot, but need to shutdown it and then startup after change some code, even if I am using --daemon, it still need some manually work. Anyway to load the code automatically?
A live mode for Gradle is in the works but not currently available. Plugins such as spring-boot may of course provide their own solution.
Few days back I created a maven project and i'm using angularJS for view, but whenever i make changes in the html file it doesn't show up after running the project, i clean the project countless number of times but the changes still don't show up.
But what i don't understand is that sometimes the changes show up the next day I run the project.
So is there some kind of cache that i need to delete after making new changes to my project??
I'm using STS Version: 3.3.0.RELEASE.
Thanks,
-Elysium
It sounds like your JavaScript files are not being copied over to the target directory properly. Make sure that after you do a build in the workspace that the proper version of the JS files are in the target folder on the filesystem (i.e., look outside of Eclipse). If the files are not correct, then your maven commands are not being completely invoked inside the workspace.
It's hard to say exactly what is going on without more information, but this sounds possible.
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.