So I've been using spring boot dev tools as a means to hot swap files when I make small changes. The problem I'm having right now is I have been using .pebble files which are located in the resources/templates file in my spring project. Dev tools was working initially with my html files but when I switched to using .pebble it stopped. I tried doing the following where I added this line of code in the application.properties file but it didnt work:
spring.devtools.restart.additional-paths=static/**.
Is there a way I can get dev tools to look specifically for .pebble files or just any file type in that folder and when there are changes hot swap them? Here is my folder config if that helps. Thanks!
Did you check if pebble cache is enabled ? By default it is. You can disable it in your application.properties with the following value:
pebble.cache=false
Related
There's one thing I never understood after so many years of using Spring IDE and Spring Tool Suite (STS).
I'm using XML configuration files. One file (say "applicationContext.xml") imports other XML files, through the use of:
<import resource="classpath:path/to/otherContextFile.xml" />
In my Eclipse project properties, under Spring | Beans Support, the option "Enable support for <import/> element in configuration files" is enabled.
In the same project properties page, if the list of the configuration files only contains applicationContext.xml, STS is nevertheless able to detect the contents of otherContextFile.xml and parses it correctly.
However, what I see is that if STS performs an autodetection of configuration files, it always adds to that list otherContextFile.xml as well. But adding all the imported configuration files to that list sounds like the option "Enable support for <import/> element in configuration files" is then useless to me. Since I like to keep my project setup clean and tidy, when this happens I usually remove the imported files from that list.
However, every now and then, the automatic scan is triggered (maybe on STS upgrade or I don't know...) and those files are re-added. This makes me think that it might be a better choice to keep them listed anyway...
So, the question is: what is more correct, elegant and efficient (from a performance point of view)? Just list the "root" configuration files or all of them (even the imported ones)? And if the answer is the latter, what's then the point of that option "Enable support for <import/> element in configuration files"?
The main purpose of the "Enable support for <import/> element in configuration files" is exactly what you are using it for and what you describe at the beginning of your question. Therefore I think you are using it in the "right" way (from the STS tooling perspective).
The automatic scan should not add those imported files to the list of used Spring config files in the project properties. It does that for specific files only, like Spring Boot application main classes or files that are listed in the web app. I have no idea at the moment why those imported files are added to that list every once in a while. This could be a bug or could be caused because the mechanism finds those files being used somewhere else.
I would love to take a more detailed look, so it would be great if you could create a small sample app that reproduces this behavior and create a GitHub issue for this problem at: https://github.com/spring-projects/spring-ide/issues. Please attach the sample project and a few steps how to reproduce the issue.
In addition to that you can disable the "automatic scanning" per project or for your entire workspace (to quickly get rid of this behavior). You can deactivate specific automatic configs via the project properties (the third tab, next to the list of config files). The "global" disable can be activated in the general "Preferences -> Spring -> Beans Support" and then "Disable Auto Config Detection".
Hope this helps!!!
When submitting an app and test assembly to Xamarin Test Cloud using test-cloud.exe (version Xamarin.UITest.1.3.9.1500-dev) we also need to submit an App.config file (as our test assembly relies on configurable appSettings).
Initially I had hoped that everything within the bin directory (either Debug / Release depending on --assembly-dir provided) would be uploaded to Test Cloud.
This does not appear to be the case, my App.config file (XamarinMobileTests.dll.config) present in the bin directory is not uploaded.
So, to address this issue, I have attempted 2 potential solutions, none of which I have had any success with, these are as follows:
Using the --data parameter with the submit command (--data XamarinMobileTests\bin\Release\XamarinMobileTests.dll.config). This always seems to return an error: "Data files must be located in the assembly directory or a sub folder."
I have attempted to put this file in various locations, with no luck.
Specify appSetting values within the --test-params parameter. This executes the submit command without error and instantiates a test run in test cloud. However, the Xamarin.UiTest Sdk does not seem to have any support for accessing the --test-params specified. My only option seems to be using the Xamarin Web Api, figuring out the test run (also not available via the Sdk) and then fetching the test-params from the test run meta-data.
The documentation on their site is extremely limited for these parameters.
Has anyone experienced similar issues in the past or found a potential solution?
Ideally, the config file is uploaded by default. However, if this is not an option, then solution 1 would be my preferred choice.
Turns out the issue was with a trailing "\" on the --assembly-dir that was causing the config file specified in --data to not be uploaded.
Changing:
".\XamarinMobileTests\bin\Release\"
to:
".\XamarinMobileTests\bin\Release"
Resolved the issue and the config file was successfully uploaded.
It looks as if the test-cloud.exe does some flakey comparisons on file paths.
I'm working on existing (not mine) Maven project which generates pretty big .war file ~37MB. More than 20MB is made of ExtJs 4.1 files (.js and .css).
I'm not sure which files are really required and which can be removed. I found out that I can remove unnecessary files with Sencha CMD but I'm not sure if it is compatibile with ExtJs 4.1. However, I tried to run it, but it always says Command must be run from an app or package folder.
Here is structure of my project: http://prntscr.com/4o97zy
Any help is apperciated!
In production you can just ext-all.* and remove rest of them which reduces size application size by 10MB. Here is the bare minimum structure that you can have in production. If you use any additional plugins include them as well. I would suggest to keep ext-all-debug.js/css as well, use maven profiles to take care of copying ext-all.* or ext-all-debug*.
The above structure is of size 2.5MB, more or less that will almost be sufficient. You can miniify these files and put it into your war. There are multiple ways of doing it. You can use ycompressor to compress and put it in your webapp or from server side you can compress files whenever user requests(Google-web utilities).
I'm working in a solution which includes a windows service host project that uses a single app.config file which contains everything the service needs (logging configuration, WCF configuration, custom configuration, and, connection strings).
The way I actually work is when a user complains about something wrong in the production environnement, I edit the app.config file, modify the connection string so it points to the production database, recompile the service host project, then run the application in my dev environnment to see what's going on.
If I have to test things that would be too risky for the production environment, I edit again the app.config file, modify the app.config file so it points to the test database, recompile the service host project, ... you see where I'm going ...
To avoid the burden of editing the app.config file everytime I have to switch environments, I decided to create a "Production" build configuration and a "Test" build configuration. I added two additionnal config files, one for each environment, which are replicas of the main app.config file except that their connection string points to their respective database. I modified the pre-build event of the project to include code that copies the environment's app.config file depending of the selected build configuration.
I have two concerns about that method :
If I have anything else to modify in the app.config file (WCF, logging, etc.) I have to remember to replicate my modification in the other file. (Big problem for me as I have as much memory as a red fish)
I hate making the project more complex to work with because of the additional build events, additional files in the project directory, etc.
Each build configuration outputs in a different directory. I hate having duplicates of the same code just to overcome that data source issue.
Anybody can suggest a simpler way to work with multiple environments ?
Thanks in advance.
I have a collection of web service and sites all installed on the same machine which share settings so I have put them in an external config file one folder above the application folders such as below.
<appSettings file="../common.config"/>
I see that with Config Transforms I can change individual values within this section had my settings been inside the appSettings block but is it possible to change the file attribute itself?
<appSettings file="../common_release.config"/>
or
The config transforms are actually applied by Visual Studio upon building a deployment package; so there is no *_release* or *_debug* version in the output.
Of course, you could use what ever files you want for external configuration.