In a recent SDK update, it seems that Google has added a INFO level log into the dev_appserver that prints out each and every time a file change is detected.
This, in my opinion, just clutters up the log with information I already know thus I don't want it to be printed out on my console.
INFO 2014-11-27 09:52:43,876 module.py:391] [default] Detected file changes:
/Users/michael/app/templates/home
/Users/michael/app/templates/home/index.html
Is there any way to remove these lines from the log? Since this is a INFO level log, I can't really remove the INFO from the log_level as other INFO logs come in handy many times...
Any suggestions?
It's now an issue on the App Engine issue tracker. Vote it up for quicker resolution.
https://code.google.com/p/googleappengine/issues/detail?id=11662
This issue started to bug me also, so here's my quick-fix until devs find more permanent solution:
in path-to-SDK\google\appengine\tools\devappserver2\module.py comment out lines 424-426.
424 # logging.info(
425 # '[%s] Detected file changes:\n %s', self.name,
426 # '\n '.join(sorted(file_changes)))
Just have to remember to do it again when the build changes, if they don't fix it. (I'm working with 1.9.20 atm) (:
As Derek Perkins pointed out, this was sent to the App Engine Issue tracker. Since I had the same problem I starred the issue. I was happily surprised to see it was actually sent up to engineering and they updated the tracker today with a workaround. I rewrote parts of it and added a bit of formatting :)
Root cause of the problem
The main reason behind why every file in a project's folder is tracked is because the reload logic is naïve and has no way of knowing which files are actually being in use.
In the event that some data file contents are changed, but only loaded at module import time (for instance templates in some frameworks), it's difficult for the devserver to accurately detect such changes.
Workaround for Git and Mercurial
If you put your project folder anywhere but the root of your git repo, it will make all the .git files appear outside of your project's dir, so the changes to the files should not be seen and therefore shouldn't trigger a webserver reload. For instance build your project's structure this way :
myproject/
myproject/.git/
myproject/.gitignore
myproject/myapp/
myproject/myapp/app.yaml
myproject/README
Then run the devserver inside of myproject/myapp instead of "myproject".
There is also a mention that this has been tested on Git and Mercurial, but it won't work on CVS or SVN.
Related
There seems to be countless reports of this bug in Stack Overflow. None of the suggestions worked. In my case it is almost identical to this stack overflow report
SPRING
except this case is in Android being built in Android Studio. It only happens in release mode with proguard. Proguard corrupts it somehow. And yes I have done the following in proguard:
-keep class org.eclipse.paho.client.mqttv3.logging.JSR47Logger { *; }
-keep class org.eclipse.paho.** { *; }
I have also parsed the jars downloaded by gradle. I cannot update to 1.2.1 because that only works with the latest versions of Android ... according to comments made by the developers. If I could get the source code for 1.1.0 maybe I could stop it from calling a resource that does not exist.
Anyone solve this problem or is it a bug in proguard/paho?
Looking at the apks generated by release builds (uses proguard) and debug builds (no proguard) shows that proguard is taking the org.eclipse.... package name of the properties and changing the 'org' to some letter like 'c'. The mqtt paho client is looking for the property file using the full package name and therefore cannot find it, no matter what you include or exclude in proguard. I looked at an apk made a few months ago (I have not done anything with the paho client or that part of the code using the paho client ... it has worked fine and I have had no need to change it). I see in that old release apk that the 'org' is there as it should be.
So the problem is in proguard. All I could do to move forward is take the source files for 1.1.0, create a new java project module, and tediously comment out every 'log' and getLogger in the source code. Its a temporary and unpleasant fix but it works. When proguard (R8) fixes this, then I can go back to what I had.
So I guess the only real fix is to submit a bug to R8. That I have not done.
I'm currently following the Vespa tutorials, and ran into an issue with the HTTP API use-case. Everything works fine from the mvn install package to the vespa-deploy prepare target/application.zip.
The call to vespa-deploy activate returns normally, but the application then never gets available on localhost:8080. Looking at /opt/vespa/logs/vespa/vespa.log (in the VM) one finds the following stack trace:
Container.com.yahoo.jdisc.core.StandaloneMain error Unexpected:
exception=
java.lang.IllegalArgumentException: Could not create a component with id 'com.mydomain.demo.DemoComponent'.
Tried to load class directly, since no bundle was found for spec: sample-app-http-api-searcher.
If a bundle with the same name is installed, there is a either a version mismatch or the installed bundle's version contains a qualifier string.
at com.yahoo.osgi.OsgiImpl.resolveFromClassPath(OsgiImpl.java:48)
...
This occurred using a fresh Docker image with a clean clone of the sample-apps git repository. Preparing and activating the basic sample as well as the other http example did work seamlessly.
I checked the sources and the xml files for obvious problems but don't have any clue about what is failing and where.
target/application.zip contains
application/components/http-api-using-searcher-1.0.1-deploy.jar
application/hosts.xml
application/searchdefinitions/basic.sd
application/services.xml
And the jar itself does contain a com/mydomain/demo/DemoComponent.class file (among other things).
Potentially related issue on the github tracker: https://github.com/vespa-engine/vespa/issues/3479 I'll be posting a link to this question there as well, but I still think it's worth a SO question, at least to get some action behind the vespa tag :)
The bundle id in the application's services.xml file was wrong. Please pull the application from git and try again now. See also PR: https://github.com/vespa-engine/sample-apps/pull/18
Brief explanation: The bundle id given in the bundle="<id>" declaration in services.xml must match the 'Bundle-SymbolicName' in the bundle's manifest. When the bundle has been built with the Vespa bundle-plugin, the symbolic name is by default the same as the project's artifactId. Hence, in most cases you just have to verify that the bundle id matches the artifactId.
I'm attempting to update an application which takes advantage of two modules (default and batchratings).
After running 'appcfg update app.yaml batchratings.yaml', I receive the following output:
Error 400: --- begin server output ---
Validation error: Invalid dispatch configuration - module 'batchratings' does not exist. Upload a version of this module and try again.
Given that that's precisely what I'm attempting to do by following the steps outlined in the Modules walkthrough, I'm fairly certain I'm overlooking something obvious.
The source is available here:
https://dl.dropboxusercontent.com/u/7537204/literumble.zip, if that helps anyone.
I'd be very appreciative if anyone had some insight to provide regarding which direction I should be looking to ferret out the issue.
I had the same issue, I was trying to do something like:
appcfg.py update <my_app_dir> app.yaml batchratings.yaml
but the appcfg.py help update shows that if you pass a directory it will always take app.yaml. To take the other modules you need to use the file path for each:
appcfg.py update <my_app_dir>/app.yaml
appcfg.py update <my_app_dir>/batchratings.yaml
To figure this out, it helped me to pass -v to make sure it was updating the module i passed.
If your app has modules then, rather than running appcfg.py my_app_dir, you can instead cd my_app_dir and then run appcfg.py app.yaml mod1.yaml mod2.yaml etc.
Do not run appcfg.py *.yaml otherwise you risk including dispatch.yaml, if present, because that will fail with "Unexpected attribute 'dispatch' for object of type AppInfoExternal".
And be sure to run appcfg.py update_dispatch . afterwards, to upload dispatch entries.
I first thought it had something to do with the app.yaml not having the modules, but that's incorrect as per the examples I'm looking at.
I think it may actually be a very silly thing, in which your dispatch.yaml is pointing to 'batchratings' but your actual module name is 'BatchRankings.py'. Notice the capitalization.
I am trying to import DebugKit and CakePHP is producing the following error: DebugKit.ToolbarComponent could not be found.
Right below it, it says:
Create the class ToolbarComponent below in file:
/Users/SomeUser/Sites/SomeProject/app/Plugin/DebugKit//Controller/Component/ToolbarComponent.php
If you notice though, there are two slashes between DebugKit and Controller for some reason, and that's obviously not a real directory. The server running PHP 5.4.17. I have followed the exact installation instructions listed here. Any suggestions?
I had the same problem and solved it by changing the permissions to 755 to folders within DebugKit.
When I encountered this problem, I realized I had a Plugin/DebugKit folder structure in my project's root, and under the app directory. The one under app was empty, save for a blank file called empty. Strange. I have no idea how this happened. (Perhaps from accidentally running composer as non-root?) I deleted app/Plugin/DebugKit, and moved the one from the project root into app. No more error.
DebugKit does not currently seem to be compatible with cakephp 3.0 even though it is the example in the documentation.
The latest version still seems to use the 2.x methods.
I will also submit a ticket regarding this to update their documentation to prevent confusion.
If there is something I missed regarding this issue and it is actually possible to install this, let me know.
I have a menu link with the alias "inside" on a joomla 3.1.5 site here: http://naiwellness.com
Every morning I check the site and a folder named "inside" has been created in the root dir which prevents the site from loading as it should, instead displaying a directory contents listing at http://naiwellness.com/inside
Anyone have any ideas how to prevent this please?
Thanks
This is just a theory, but check the xml files of your installed modules and plugins (most likely a plugin) for this line...
<folder>inside</folder>
and if it exists try deleting that line of code - or better still uninstall the extension - that should fix it. It's possible that a plugin requires that folder and has php code to create the folder if it doesn't exist - and so creates the folder each time it is run - i.e. when the site is loaded. The above line of xml code I have asked you to look for will go someway to helping determine if this is the case.