I am using STS and sometimes when I stop my app on a crash it opens up to a hundred different class files that seem to be deep deep inner working stuff. HTTPBuilder just stopped working, and I suspect its because I accidentally typed in one of these files and absent mindedly saved it. If I somehow destroyed a local file involved in HTTPBuilder, how would I refresh my dependencies? (have done install-plugin rest and also uncommented everything in BuildConfig.groovy repositories)
My specific problem and error is here:
Grails: HTTPBuilder stopped working suddenly
UPDATE: As much as I would love to blame STS, as you can see from my answer to my own other question, I was purely thwarted by my own carelessness.
We had an issue today that we suspect was due to the Artifactory Migration. Your problem may be similar. The first thing we did to diagnose the issue was to turn up the debug logging in BuildConfig.groovy (change log "warn" to log "debug"). Once we did that, it was evident that the Grails repos in Artifactory appear to be responding differently to queries made to calculate dependencies. To workaround these issues, we:
Removed grailsCentral, grailsHome, and grailsPlugins from BuildConfig
Added grailsRepo "http://grails.org/plugins" to BuildConfig
Changed one of our dependencies so that its transitive dependencies used specific versions instead of version ranges.
For 3, our specific example was to change:
runtime 'com.amazonaws:aws-java-sdk:1.3.4'
to
runtime 'com.amazonaws:aws-java-sdk:1.3.4', {
excludes "commons-logging",
"httpclient", "jackson-core-asl", "jackson-mapper-asl"
}
runtime 'org.codehaus.jackson:jackson-core-asl:1.7.9' {
configurationmapping "*->*,!sources,!javadoc"
}
runtime 'org.codehaus.jackson:jackson-mapper-asl:1.7.9' {
configurationmapping "*->*,!sources,!javadoc"
}
I'm not sure whether all of these steps were necessary, but they allowed us to move forward.
Related
In Grails 2 we used the "External configuration plugin", which included the method checkNow() for checking and refreshing values from an external config file.
Does it exist a simple approach for doing something similar in Grails 4+? I have seen references to Spring Cloud Config Server, but it seems a bit overkill for me. All I really want to do is be able to (now and then) update a config value in runtime. It could also be purely by a few lines of code, and does not have to originate from changes in the config file. This would avoid having to restart our server for minor changes in config. Thanks!
I'm replying to myself with a ridiculously simple answer: "just change it". Using the console plugin (or any other form of code execution), I can just assign grailsApplication.config.any.property a new value. It won't persist and it won't update any listeners or anything. But it is a glaringly obvious solution that I just assumed wouldn't work due to the getProperty() calls (I interpreted the name as reading from file) and googled discussions about Spring Cloud Config.
So, move on... nothing to see here. Just mild embarrassment :-P
change a config.properties file in a jar / war file in runtime and hotdeploy the changes ?
my requirement is something as follows, we have a "config.properties" in a jar/war file , i have to open the file through a webpage and after the user has made necessary changes to it, i have to update the "config.properties" in jar/war file and hot deploy it. can we achieve this feat ? if so can you please point me to relevant sites/documents so that i can jumpstart on this.
I will strongly recommend your architecht rethink this solution. What you describe should be done through JNDI or a similar technique, not through reloading properties.
Deployments should be considered static - that any given web container allows for magic trickery should not be depended on, and WILL break some day (most likely at the most inconvenient time).
You've got a couple of problems off the top of my head:
ensuring that nothing is holding static references to a java.util.Properties that has previously loaded your config.properties file.
most servlet engines will unpack your war to a working directory so the properties file you load won't be the one in the war, it will be the unpacked one. This means your changes
will be overwritten when you restart the servlet engine because this is typically one of the points the war is unpacked.
While these problems aren't insurmountable I've always found it much easier to implement this sort of behavior by storing the properties in JNDI (as Thorbjørn suggests) or a database (while being careful about the static references I mentioned in point 1).
The JNDI/database solution has the nice side effect of easing deployment into multiple environments because each typically has it's own registry/database.
Even that I agree with the comments explained before, I could suggest one solution:
Apache Commons Configuration extension gives you the posibility to do something like:
config.setReloadingStrategy(new FileChangedReloadingStrategy());
That could make the trick to change the configuration file on a runtime basis with no code at all.
However, like JNDI and other methods of web application configuration, the security is a concern. Be careful on which parameters you can/must be able to configure.
It looks like IntelliJ's (Ultimate EAP 15) support for Grails 3 is in the early stages yet. If I do Run -> Debug 'Grails:My App', I'm able to launch an app from inside IntelliJ, I can set breakpoints and it works as expected.
If I make changes however, I see in the console that the file is recompiled, but when I hit reload in the browser, I don't see the changes reflected there. I have to stop and restart the app in IntelliJ before I see them. Anyone know how I can get the auto-reloading working?
After chasing this for a week, this post finally provided an explanation.
It's actually a Grails issue, not a problem with IntelliJ's Grails integration: spaces in a file's path will break automatic reloading. Renaming my project from Grails Demo to GrailsDemo got everything straighted out. (Storing a project in a folder like My Documents will also cause trouble.) The post's author indicates that this started with version 2.4.4 and it's still happening for me in 3.0.4.
I'm working on an Umbraco cloud project. I pulled the website from the git repositories and built it. First thing to do there when you run the site is to restore the content that's in the development environment to the local project so we can create new features. Yet Umbraco fails to do so with the following error:
The source environment has thrown a Umbraco.Deploy.Exceptions.ProcessArtifactException
with message: Process pass #3 failed for artifact
umb://document/xxthexguidxofxsomexpagexxxxxxxxx. It might have been
caused by an inner Umbraco.Deploy.Exceptions.EnvironmentException with
message: Could not get parent with id xxthexxx-guid-xofx-xthe-xxhomepagexx.
The following artifacts might be involved:
umb://document/xxthexxxguidxofxxthexxhomepagexx
The technical details may contain more information.
I've noticed that I some strange errors occur if not everything is deployed in the development site in the cloud. So I made sure everything is published.. Still errors though... I'm kinda lost here.
Has anyone come across simular issues? And how did you fix it?
Thanks in advance?
This can happen for a number of reasons, so it's a bit hard to say what exactly the problem is in your case.
Most of the time this happens due to either a circular reference of some sort causing a state that can't really be restored. For example that could be a datatype having a dependency on a node - but the node doesn't exist in a blank new environment. The content restore then refuses to start until the structural data (datatypes, contenttypes and such) is completely in sync, but the datatypes will never be able to be in sync until the content node exists. It's a sort of catch22 situation that might need to be resolved manually.
I would suggest you contact support through the Cloud portal and they will assist you in getting your problem resolved.
I am having some trouble setting up spring security in my application so I tried to install spring-security-eventlog-0.3 in order to see the logs and understand what the hell is going on :))))
I added this line in BuildConfig.groovy
compile ":spring-security-eventlog:0.3"
When I hit run-app I get this very beautiful message
SpringSecurityEventlogGrailsPlugin.groovy: 3: unable to resolve class org.codehaus.groovy.grails.plugins.springsecurity.SpringSecurityUtils
# line 3, column 1.
import org.codehaus.groovy.grails.plugins.springsecurity.SpringSecurityUtils
^
SpringSecurityEventlogGrailsPlugin.groovy: 2: unable to resolve class org.codehaus.groovy.grails.plugins.springsecurity.SecurityEventListener
# line 2, column 1.
import org.codehaus.groovy.grails.plugins.springsecurity.SecurityEventListener
The run failed. I decided to remove it because I didn't feel like spending hours for that. The thing is that even though I removed the line from BuildConfig, it tries to install it every single time! I even went in my hard disk's path and removed the folder. Even though it installs it every time and fails of course.
Could you please suggest me a solution on this? I would prefer to keep the plugin and be able to have the spring security logs. If it is not possible for some reason, I would like to be able to remove it.
As mentioned in the comments, that plugin depends on version 1.2.x of the core plugin, so you either need to downgrade to 1.2.7.3, or wait until the eventlog plugin is updated to use the 2.0 plugin.
I updated the plugin and sent a pull request, and hopefully the author will release an updated version soon. Feel free to bug him about this if he doesn't :)